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Description 

[0001] This invention relates to a digital software car- 
rier/player and data stream for controlling display of sub- 
titles during play of the software (e.g. motion picture) 
carrier, and more particularly to a technique by which 
subtitles in multiple languages are recorded on the 
same carrier with provision for selecting one language 
for display. 

Background Of The Invention 

[0002] The most widespread medium for distributing 
motion pictures is the videocassette. The conventional 
practice is to provide only one language soundtrack on 
each videocassette. Similarly, if subtitles are to be pro- 
vided, e.g. French language subtitles for an "English" 
motion picture to be distributed in France, only subtitles 
in that language will appear (Subtitles in two languages 
are possible, but this obviously Interferes even more 
with the video). This means that different audio and sub- 
title versions of the same "foreign" motion picture must 
be prepared for distribution In different countries. 
[0003] Rather than to dedicate a different dialog-lan- 
guage and subtitle-language version of the same motion 
picture for each combination of dialog and subtitle lan- 
guages (If each of 20 dialog languages is to have sub- 
titles In the other 1 9 languages, 380 different dialog/sub- 
title versions would be necessary), It would be far more 
advantageous to provide multiple sound-tracks, con- 
taining different dialog languages, and multiple lan- 
guage subtitle captions on the same carrier; this would 
require the production of far fewer versions of the same 
motion picture. Because of the large storage require- 
ments, however, this has not proven to be practical; 
[0004] Digitally encoded optical disks are In theory far 
superior for the distribution of motion pictures and other 
forms of presentation. Especially advantageous Is the 
use of "compressed video", by which It Is possible to dig- 
itally encode a motion picture on a disk no larger than 
the present-day audio CD. While much effort has been 
expended In developing compressed video systems, 
less work has been devoted to the provision, of multiple 
soundtracks and multiple subtitles on the same software 
carrier. 

[0005] WO-92 00647 discloses an apparatus and a 
method where several subtitles may accompany a video 
program. The language in which the subtitle data ap- 
pears is user selectable. French Patent Specification 2 
586 879 relates to a method which makes it possible to 
record several versions of one subtitling. With the sub- 
titles being transmitted ahead of the image, the digital 
data which represent them are modulated Into a form 
compatible with recording on one of the sound tracks of 
a general-public stereophonic video recorder and the 
said data are recorded with an Instantaneous bit rate 
which is less than the bit rate of the digital data. 
[0006] It is therefore an aim of this Invention to provide 



a system for playing a software carrier, such as an op- 
tical disk, on which a motion picture has been recorded 
accompanied with subtitles in multiple languages. (The 
provision of multiple dialog language soundtracks, while 
s described, Is not claimed herein other than in combina- 
tion with the provision of multiple subtitle languages). 

Summary Of The Invention 

10 [0007] According to the present invention, there Is 
provided a digital software earner and compatible player 
as defined In claim 1 below. According to the present 
invention, there is further provided a digital software car- 
rier as defined in claim 3 below. According to the present 

15 invention, there is still further provided a data stream 
containable or derived from a digital software carrier as 
defined in claim 5 or claim 7 below. 
[0008] Before summarising the invention further, it is 
to be appreciated that the embodiments of the present 

20 Invention contemplate data-efficient storage and recov- 
ery of various audio and subtitle presentations, and not 
Just different language movie soundtracks and subtitles. 
For example, multiple soundtracks and subtitle captions 
could Include teaching and testing versions of the same 

25 material, and there could perhaps be teaching and test- 
ing versions for multiple levels of expertise. Thus, it is 
to be understood that an aim of the invention Is to pro- 
vide a plurality of subtitle sequences synchronised with 
a motion picture (video and audio), and not necessarily 

30 such sequences which differ only In terms of language. 
It is also to be understood that the embodiments are not 
limited to a particular medium, and it Is applicable to tape 
earners and ail digital storage media, not just the optical 
disks of the Illustrative embodiment of the Invention. Nor 

35 are embodiments limited only to the distribution of mo- 
tion pictures. For example, in an extreme case, the in- 
vention is applicable to the distribution of a library of stilt, 
pictures, in which case there is no "motion" at ail. The 
terms "subtitle tracks" and "subtitle sequences" thus 

40 embrace much more than movie subtitles In different 
languages, the term "software publisher" thus embraces 
much more than a motion picture company, and the term 
"carrier" embraces much more than a digitally encoded 
optical disk. As used herein, the term "subtitle" refers to 

45 any text, displayed anywhere on an image. 

[0009] The illustrative embodiment of the invention Is 
an optical disk which includes multiple audio tracks and 
multiple subtitle tracks synchronized with a motion pic- 
ture track. The user selects one of the audio tracks, the 

so French track, for example, If he wants to hear the French 
version of the movie. If there is no audio track in hismer 
language, this selection is not particularly important. 
What is more significant in such a case is the selection 
of the subtitle language. 

55 [0010] The disk includes within its lead-in section a 
series of codes which Identify the available subtitle lan- 
guages. There are a maximum of 99 subtitle tracks 
which may be provided. It Is necessary to Identify which 
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languages are available on the disk so that the user can 
control his player to generate subtitles In the desired lan- 
guage, by reading subtitle sequences in a selected 
track. 

[0011] Information recorded on the software carrier is 
recorded in separately identifiable blocks. This is true 
for both video, al! of the synchronized audio, and all sub- 
titles, Each block contains indicia of which subtitle tracks 
In the block contain update information. In general, once 
a subtitle caption is generated, it remains In view. It Is 
removed, with or without a new subtitle taking its place, 
only when new subtitle data Is read from the carrier. All 
it takes is a single bit for each of the subtitle tracks at 
the beginning of a biock to allow the player to determine 
whether respective language-specific subtitle informa- 
tion is in the block being processed. 
[0012] Other features of the invention will be de- 
scribed below. For example, a citizen of Spain, who pur- 
chases a player and optical disks in Spain, can be as- 
sumed to want to see Spanish subtitles of a "foreign" 
motion picture. Therefore, a player sold in Spain should 
"default" to play of a Spanish subtitle track if one is avail- 
able on the disk (assuming that subtitles are desired at 
all). Only if the default language is not available, or the 
user actually wants to see subtitles in a different lan- 
guage, should she be required to choose from among 
the available languages. How the data is stored on soft- 
ware carriers, and how it is accessed and played, will 
be discussed at length below. 
[001 3] The invention is disclosed in the context of an 
overall system which offers numerous advantageous 
features. The entire system is described although the 
appended claims are directed to specific features. The 
overall list of features which are of particular Interest in 
the description below include: 

• Video standard and territorial lock out 

• Play in multiple aspect ratios. 

• Play of multiple versions, e.g., PG-rated and R-rat- 
ed, of the same motion picture from the same disk, 
with selective automatic parental disablement of R- 
rated play. 

• Encrypted authorization codes that prevent unau- 
thorized publishers from producing playable disks. 

• Provision of multiple-language audio tracks and 
multiple-language subtitle tracks on a single disk, 
with the user specifying the language of choice. 
Provision ofmultiple "other" audio tracks, e.g., each 
containing some component of orchestral music, 
with the user choosing the desired mix. 

• Variable rate encoding of data blocks, and efficient 
use of bit capacity with track switching and/or mix- 
ing, to allow all of the above capabilities on a single 
carrier. 

[0014] Further objects, features and advantages of 
the Invention will become apparent upon consideration 
of the following detailed description in conjunction with 



the drawing, in which: 

FIG. 1 depicts a prior art system and typifies the lack 
of flexibility in, and the poor performance of, pres- 
s ently available media players: 

FIG. 2 depicts the Illustrative embodiment of the in- 
vention;. 

FIG. 3 is a chart which lists the fields In the lead-In 
portion of the digital data track of an optical disk that 
fo can be played In the system of FIG. 2; 

FIG. 4 is a similar chart which lists the fields in each 
of the data blocks which follow the lead-in track sec- 
tion of FIG. 3: 

FIGS. 5A-5E comprise a flowchart that illustrates 
'5 the processing by the system of FIG. 2 of the data 
contained In the lead-in track section of an optical 
disk being played; 

FIG. 6 is a flowchart that illustrates the processing 
of the data blocks, in the format depleted in FIG. 4, 

20 that follow the lead-in section of the track; 

FIG. 7A is a state diagram and legend that charac- 
terize the manner In which the player of the inven- 
tion reads only those data blocks on a disk track that 
are required for the play of a selected version of a 

25 motion picture or other video presentation, and FIG. 
7B depicts the way in which one of two alternate 
versions can be played by following the rules Illus- 
trated by the state diagram of FIG. 7A; 
FIG. 8 depicts symbolically a prior art technique 

30 used in compressing the digital representation of a 
video signal; and 

FIG. 9 illustrates the relationships among three dif- 
ferent image aspect ratios. 

35 The Prior Art 

[001 5] The limitations of the prior art are exemplified 
by the system of FIG. 1. Such a system Is presently 
available for playing a single source of program materi- 

40 al, usually a VHS vldeocassette, to generate a video sig- 
nal conforming to a selected one of multiple standards. 
A system of this type is referred to as a multi-standard 
VCR, although stand-alone components are shown in 
the drawing. Typically, a VHS tape 7 has recorded on it 

45 an NTSC (analog) video signal, and the tape is played 
in a VHS player 5, The analog signal Is converted to dig- 
ital form in A/D converter 9, and the digital representa- 
tions of successive frames are written into video frame 
store 11 . Circuit 13 then deletes excess frames, or esti- 

so mates and adds additional frames, necessary to con- 
form tD the selected standard, e.g., PAL. To convert from 
one standard to another, it Is generally necessary to 
change the number of horizontal lines In a field or frame 
(image scaling). This Is usually accomplished by drop- 

55 ping some lines, and/or repeating some or averaging 
successive lines to derive a new line to be Inserted be- 
tween them. The main function of circuit 13, of course, 
Is to convert a digital frame representation to analog 
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form as the video output. 

[001 6] Systems of the type shown in FIG. 1 generally 
degrade the video output. Conventional vldeocassettes 
deliver reduced quality video when they support more 
than one video standard. One reason Is that there is a 
double conversion from analog to digital, and then back 
again. Another Is that the image scaling is usually per- 
formed in a crude manner (deleting lines, repeating lines 
and averaging lines). There are known ways, however, 
to perform Image scaling in the digital domain without 
degrading the picture. While not generally used, the 
technique is in the prior art and will therefore be de- 
scribed briefly as it is also used in the illustrative em- 
bodiment of the invention. 

[001 7] To give a concrete example, the PAL standard 
has 625 lines per frame, while the NTSC standard has 
525 lines per frame. Because no part of the image is 
formed during the vertical retrace, not all of the horizon- 
tal line scans in either system are usable for represent- 
ing Image information. In the PAL standard there are 
nominally 576 lines per frame with image information, 
and in an NTSC frame there are nominally 4B3 lines with 
image Information. 

[0018] To convert from one standard to another, suc- 
cessive fields are first deinterlaced. Then 576 lines are 
converted to 483, or vice versa, and relntertaced. How 
this is done is easy to visualize conceptually. Consider, 
for example, a very thin vertical slice through a PAL 
frame. The slice is broken down into its three color com- 
ponents. Image scaling for converting from PAL to NT- 
SC, from a conceptual standpoint, is nothing more than 
drawing a curve based on 576 PAL pieces of color data 
and then dividing the curve into 483 parts to derive a 
piece of data for each horizontal line of the desired NT- 
SC signal. In actuality, this is accomplished by a process 
of interpolation, and it is done digitally, (image scaling, 
in general, may also Involve a change in the aspect ratio, 
for example, in going from HDTV to NTSC, and may re- 
quire clipping off Information at both ends of every hor- 
izontal line.) 

[0019] While prior art systems thus do provide for 
standards conversion, that is about the extent of their 
flexibility. The system of FIG. 2, on the other hand, offers 
unprecedented flexibility In ways not even contemplated 
in the prior art 

The Illustrative System Of The Invention 

[0020] The system of FIG. 2 includes a disk drive 21 
for playing an optical disk 23. Digital data stored on the 
disk appears on the DATA OUT conductor 25. The disk 
drive operation is governed by microprocessor disk 
drive controller 27. The read head is positioned by com- 
mands issued over HEAD POSmON CONTROL lead 
29, and the speed of the disk rotation Is governed by 
commands issued over RATE CONTROL conductor 31 . 
Optical disks are usually driven at either constant linear 
velocity or constant angular velocity. (Another possibility 



involves the use of a discrete number of constant angu- 
lar velocities.) Disks of the invention may be driven at 
constant linear velocity so that the linear length of track 
taken by each bit is the same whether a bit is recorded 

5 In an inner or outer portion of the track. This allows for 
the storage of the most data. A constant linear velocity 
requires that the rate of rotation of the disk decrease 
when outer tracks are being read. This type of optical 
disk control Is conventional. For example, the CD audio 

10 standard also requires disks which are rotated at a con- 
stant linear rate. 

[0021] Microprocessor 41 is the master controller of 
the system. As such, it issues commands to the disk 
drive controller over conductor 43 and It determines the 

15 status of the disk drive controller over conductor 45. The 
disk drive controller is provided with two other inputs. 
Block number/pointer analyzer 47 issues commands to 
the disk drive controller over conductor 49, and BUFF- 
ER FULL conductor 51 extends a control signal from OR 

20 gate 54 to the disk drive controller. These two inputs will 
be described below. (In general, although reference Is 
made to individual conductors, it is to be understood that 
In context some of these conductors are in reality cables 
for extending bits in parallel. For example, while the out- 

25 put of O R gate 54 can be extended to the disk drive con- 
troller over a single conductor 51 , block number/pointer 
analyzer 47 could be connected to the disk drive con- 
troller over a cable 49 so that multi-bit data can be sent 
in parallel rather than serially.) 

so [0022] An important feature of the system of FIG. 2 is 
that bit information Is stored on the disk at a rate which 
varies according to the complexity of the encoded ma- 
terial. By this is meant not that the number of bits per 
second which actually appear on the DATA OUT con- 

35 ductor 25 varies, but rather that the number of bits which 
are used per second varies. Video information is stored 
In compressed digital form. FIG. 8 shows the manner in 
which video frames are coded according to the MPEG1 
and MPEG2 standards. An Independent l-frame is cod- 

40 ed in its entirety. Predicted or P-f rames are frames which 
are predicted based upon preceding independent 
frames, and the digital information that Is actually re- 
quired for a P frame simply represents the difference 
between the actual frame and its prediction. Bldlrectlon- 

45 ally predicted B-f rames are frames which are predicted 
from I and/or P frames, with the information required for 
such a frame once again representing the difference be- 
tween the actual and predicted forms. (As can be ap- 
preciated, fast forward and fast reverse functions, if de- 

so sired, are best Implemented using l-frames.) The 
number of bits required to represent any frame depends 
not only on Its type, but also on the actual visual infor- 
mation which is to be represented. Obviously, it requires 
far fewer bits to represent a blue sky than it does to rep- 

55 resent a field of flowers. The MPEG standards are de- 
signed to allow picture frames to be encoded with a min- 
imal number of bits. Frame information is required at a 
constant rate. For example, if a motion picture film Is 
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represented in digital form on the disk, 24 frames will be 
represented for each second of play. The number of bits 
required for a frame differs radically from frame to frame. 
Since frames are processed at a constant rate, it is ap- 
parent that the number of bits which are processed 
(used) per second can vary from very low values to very 
high values. Thus when bits are actually read from the 
disk, while they may be read from the disk at a constant 
rate, they are not necessarily processed at a constant 
rate. 

[0023] Similar considerations apply to any audio 
stored on the disk. Any data block may contain the bit 
information required for a variable number 1 of image 
frames. Any data block may similarly contain the bit in- 
formation required for a variable time duration of a var- 
iable number of even numerous audio tracks. (There is 
just one physical track. The reference to multiple audio 
tracks is to different series of time-division slices con- 
taining respective audio materials.) The audio tracks 
contain digital information, which may also be in com- 
pressed form. This means that If there is Information 
stored in any data block for a particular audio track, 
those bits do not necessarily represent the same time 
duration. It might be thought that the duration of the 
sound recorded for any audio track corresponding to 
any picture frames represented In a block would be the 
duration of the picture frames. However, that Is not nec- 
essarily true. This means that audio information may be 
read before it is actually needed, with the reading of 
more audio information pausing when a sufficient 
amount has already accumulated or with audio not be- 
ing included in some data blocks to compensate for the 
preceding over-supply. This leads to the concept of buff- 
ering, the function of audio buffers 53, video buffer 55, 
pan scan buffer 57, subtitle buffer 59, and OR gate 54 
which generates the BUFFER FULL signal. 
[0024] As each data block Is read from the disk, it 
passes through gate 61 , provided the gate is open, and 
the bit fields are distributed by demultiplexer 63 to the 
various buffers and, over the COMMAND/ DATA line 65, 
to master controller 41 . Each data block in the illustrative 
embodiment of the invention contains video bit informa- 
tion corresponding to a variable number of picture 
frames. As discussed above, there may be a large 
number of bits, or a small number, or even no bits (for 
example, if the particular disk being played does not rep- 
resent any video). Successive groups of video data are 
stored in video buffer 55 separated by markers. Video 
decoder 67 issues a command over conductor 69 when 
it wants to be furnished with a new batch of data over 
conductor 71 . Commands are issued at a steady rate, 
although the number of bits furnished in reply vary in 
accordance with the number of bits required for the par- 
ticular frames being processed. The rate at which bits 
are read from the disk drive Is high enough to accom- 
modate frames which require maximal Information, but 
most frames do not. This means that the rate at which 
data blocks are actually read Is higher than the rate at 



which they are used. This does not mean, however, that 
a well-designed system should delay reading of a block 
of data until the data Is actually required for processing. 
For one thing, when data is actually required, the read 

s head may not be positioned at the start of the desired 
data block. It Is for this reason that buffering Is provided. 
The video buffer 55 contains the bit Information for a 
number of successive frames (the actual number de- 
pending upon the rate at which bits are read, the rate at 

10 which frames are processed, etc., as is known In the 
art), and video data block information is read out of the 
video buffer at a constant frame rate determined by vid- 
eo decoder 67. Video data is delivered to the buffer only 
until the buffer Is full. Once the buffer is full, no more 
information should be delivered because it cannot be 
stored. When the video buffer is full, a signal on conduc- 
tor 69 causes the output of OR gate 54 to go high to 
inform disk drive controller 27 that one of the buffers is 
full. 

20 [0025] Similar remarks apply to the three other types 
of buffers. (There Is a single subtitle buffer 59, a single 
pan scan buffer 57, and numerous audio buffers 53, the 
purpose of a!! of which will be described below.) When 
any of these buffers is full, its corresponding output 

25 causes OR gate 54 to control the BUFFER FULL con- 
ductor to go high and to so inform the disk drive control- 
ler that one of the buffers is full. Audio buffers 53 and 
subtitle buffer 59 operate in a manner comparable to 
that described for video buffer 55. Audio processor de- 

30 coder 71 Issues a command to the audio buffers when 
it requires audio track data, at which time the audio buff- 
ers furnish such data. Similarly, graphics generator 73 
retrieves data from subtitle buffer59, and pan scan proc- 
essor/vertical scaler 87 receives data from pan scan 

35 buffer 57 as will be described below. 

[0026] When any one of the four buffers is full (which 
Includes any one of the Individual buffers within the 
block 53), the disk drive controller 27 causes the disk 
drive to stop reading data. Data is not read again until 

40 all of the buffers can accept It, I.e., until no buffer Is full 
and conductor 51 goes low. (Conversely, If the buffers 
are being depleted of data too rapidly, an adjustment In 
the RATE CONTROL signal on conductor 31 increases 
the disk speed and thus the rate arwhlch the buffers are 

45 filled.) 

[0027] This discussion of buffering arose from a con- 
sideration ofthe BUFFER FULLInput51 to the disk drive 
controller 27. The other input which remains to be de- 
scribed is that represented by cable 49. As will be de- 

so scribed below, every data block has a serial block 
number as well as pointer information at its beginning. 
Circuit 47 reads the serial block number and analyzes 
the pointer information. The pointer, a serial block 
number, points to the next data block which should be 

55 read. This information is furnished to the disk drive con- 
troller over cable 49. It is in this way that the disk drive 
controller can control positioning ofthe read head ofthe 
disk drive so that the desired data block can be ac- 
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cessed. Many times the wrong block will be read - this 
is to be expected in the case of a jump to a new block, 
as is the case, for example, when a jump is made from 
one track to another when playing a CD audio disk. If 
the disk drive reads a data block whose serial block 
number is too high ortoo low, this Is determined by block 
number/pointer analyzer 47 which then Issues a new 
command over cable 49 to the disk drive controller to 
cause it to read another block with a lower or higher se- 
rial block number respectively. During the time that the 
read head is positioning itself to read a new block, the 
data which is read is not actually used. Gate 61 remains 
closed so that the information is not delivered to the de- 
multiplexer 63 for distribution to the four buffers and to 
the master controller 41 over the COMMAND/DATA 
lead. It Is only when the correct data block is reached, 
as determined by circuit 47 analyzing the serial block 
number at the start of the block, that conductor 75 is 
pulsed high to open gate 61 . 

[002B] The remainder of the block is then delivered to 
the demultiplexer. The data bits read from the disk are 
also delivered to the microprocessor master controller 
41 over conductor 77. Each data block contains not only 
bit information which must be distributed to the various 
buffers, but also control Information, e.g., bits that Iden- 
tify the kind of data actually to be found in the block. The 
identification bits (flags and the like, as will be described 
below) are furnished to the master controller so that it is 
. in control of the system at all times. The Identification 
bits are used by the demultiplexer to control data distri- 
bution to the various buffers. (The master controller is- 
sues commands over conductor 76 to the block number/ 
pointer analyzer 47 which exercise not only general con- 
trol over this element, but also specific control by caus- 
ing element 47 to turn off the enabling signal on conduc- 
tor 75 as is appropriate to prevent full data blocks from 
entering the demultiplexer if they are not required for 
subsequent processing.) 

[0029] The master controller Is at the heart of the sys- 
tem and In fact carries out the bulk of the processing to 
be described below. The user of the player communi- 
cates with the master controller via an Interface 79, typ- 
ically a keyboard. The user also is provided with a key 
and lock mechanism, shown symbolically by the numer- 
al 81 , which is referred to herein as the "parental lock" 
option. If the lock is turned on, then R-rated motion pic- 
tures will not play. The manner in which this is controlled 
by bits actually represented on the disk will be described 
below. If the lock Is on, and only an R-rated picture is on 
the disk, a disabling signal on PARENTAL LOCK CON- 
TROL conductor 83 closes gate 61 . No data bits are 
transmitted through the gate and the disk cannot be 
played. As will become apparent below, if the disk also 
has on it a version of the film which is not R-rated, it will 
play if it is selected by the viewer. Although the parental 
lock feature is shown as requiring the use of an actual 
key and lock, It is to be understood that the feature can 
be implemented by requiring keyboard entries known 



only to a child's parents. The manner of Informing the 
master controller that R-rated versions of a motion pic- 
ture should not be viewed is not restricted to any one 
form. Just as physical keys and coded keys are alterna- 

s tlvely used to control access to a computer, so they can 
be In the system of FIG. 2. What Is Important is the way 
In which two different versions can be represented on 
the same disk (without requiring the full version of each), 
and how the system determines whether a selected ver- 

10 slon may be played in the first place. This will be de- 
scribed below. 

[0030] Master controller 41 includes several other 
outputs which have not been described thus far. Con- 
ductor 85 represents a MASTER CLOCK bus which is 

is extended to all of the sub-systems shown in FIG. 2. In 
any digital system, a master clock signal is required to 
control the proper phasing of the various circuits. The 
six other outputs of the master controller are extended 
to demultiplexer 63, audio processor decoder 71 , pan 

20 scan processor/vertical scaler 87, video frame store, in- 
terlace and 3:2 pulldown circuit 89, graphics generator 
73, and sync generator and DVA converter 92. These 
are control leads for governing the operations of the In- 
dividual circuit blocks. 

25 [0031] Audio processor decoder 71 processes the da- 
ta in buffers 53 and derives individual audio analog sig- 
nals which are extended to an amplifier/speaker system 
shown symbolically by the numeral 91. Video decoder 
67 derives a DIGITAL VIDEO signal on conductor 93 

30 from the compressed video data which is read from buff- 
er 55. The digital video is fed to pan scan processor/ 
vertical scaler 87 frame by frame. The particular video 
coding/decoding that is employed is not a feature of the 
present invention. A preferred standard wouid be one 

35 along the lines of MPEG1 and MPEG2, but these are 
only illustrative. The same is true of the audio track cod- 
ing. The present Invention Is not limited to particular cod- 
ing methods. 

[0032] The operations of circuits 57 and 87 can be 

40 best understood by first considering the symbolic draw- 
ing of FIG. 9. The digital information which is stored on 
the optical disk In the preferred embodiment of the in- 
vention characterizes frames having a "master" aspect 
ratio of 1 6:9, the so-called "wide screen" Image. The 

45 master aspect ratio Is shown on the upper left in FIG. 9. 
If the ultimate analog signal to be displayed on the user's 
television receiver requires this aspect ratio, and the 
number of horizontal scan lines with picture Information 
(as opposed to horizontal scan lines which occur during 

so vertical retrace) corresponds with the number of hori- 
zontal lines represented by the video bit Information 
stored on the disk, then the generation of the video an- 
alog signal is straightforward. But if the television receiv- 
er of the user accommodates a TV signal having a 4:3 

55 aspect ratio, and the master aspect ratio on the disk Is 
16:9 rather than 4:3, then there are two choices. One Is 
to display the original picture in "letter box" form. As de- 
picted on the right side of FIG. 9, what is done in this 
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case is to vertically compress uniformly a master image 
so that its horizontal dimension fits into the confines of 
the television receiver. This results in the vertical dimen- 
sion being shortened at the same time so that it fills less 
than the full height of the TV display area. What this 
means Is that the horizontal line scans at the top and 
bottom of each overall frame must be blanked, with dark 
bands forming in their place - but the original aspect 
ratio is preserved. The other option is for a "pan scan" 
reduced aspect ratio. What this Involves is superimpos- 
ing a box having a 4:3 aspect ratio on the original wide 
screen Image. As a result, the left side of the picture, 
the right side, or both sides, are clipped off. (In ali cases, 
even if a wide screen image corresponding to a 16:9 
master aspect ratio is to be shown, it may be necessary 
to form a number of horizontal line scans which is dif- 
ferent from the number of horizontal lines represented 
on the disk. The number of horizontal lines is a function 
of the video signal standard to which the video output 
must conform. Changing the number of lines is a proc- 
ess known as vertical scajing, as described above.). 
[0033] With respect to pan scan processing, It will be 
apparent from FIG. 9 that in order to identify that portion 
of a 16:9 master aspect ratio picture which should be 
used to form a pan scan reduced aspect ratio picture, 
all that is required is to specify the starting point along 
each horizontal line scan of the information that should 
be used. Specifying a single number (e.g., column 200 
out of a total of 960 columns) suffices for this purpose. 
The issue, however, is whether the same column is al- 
ways used. In some cases the player may be told that 
if a 4:3 aspect ratio is desired, it should always be taken 
from the middle of the wide screen image. In other cas- 
es, a variable column starting point may be desired, in 
which case a data block actually contains information 
which represents the starting column number which 
should be used from that point until another change is 
effected. 

[0034] As will become apparent below, the video in- 
formation In each data block includes a flag which rep- 
resents whether the pan scan column Information 
should be updated. If there Is such a flag, video decoder 
67 Issues a command over conductor 95 to pan scan 
buffer 57. At this time the buffer accepts a pan scan up- 
date from demultiplexer 63. That update remains in the 
buffer, for use by pan scan processor/vertical scaler 87 
with the succeeding frames, until another change takes 
place. 

[0035] It is In pan scan processor/vertical scaler 87 
that the number of horizontal lines Is adjusted and the 
aspect ratio Is changed. The digital video is furnished 
by video decoder 67 and the pan scan information, if it 
Is required, is provided by buffer 57. The output of circuit 
87 consists of uncompressed digital video, in the de- 
sired aspect ratio and represented by the number of hor- 
izontal lines required for the selected television stand- 
ard. 

[0036] Once video frame Information is stored digitally 



in frame store 89, it can be broken up Into Interlaced 
fields if the selected standard requires it. Also, 3:2 pull- 
down is the technique used to convert 24-frames-per- 
second motion pictures to 60-fields-per-second video 

s (the nominal values of 24 and 60 are in reality 23.97 and 
59.94); to convert data representative of a motion pic- 
ture to an NTSC format, frame information (data blocks) 
must be read at the rate of 24 per second. (As is stand- 
ard In the art, such a transformation applies frame 1 of 

10 the source material to fields 1 , 2 and 3 of the video sig- 
nal, frame 2 of the source material to fields 4 and 5 of 
the video signal, frame 3 of the source material to fields 
6, 7 and 8, etc., thus yielding 60 fields for 24 original 
frames.) On the other hand, conversion to the PAL 

15 standard is relatively simple, and 3:2 pulldown is not re- 
quired. The PAL standard requires 50 fields per second. 
Frames are processed at the rate of 25 per second, and 
every frame is used to form two fields. (Because motion 
picture films are shot at the rate of 24 frames per second 

so yet processed at the rate of 25 per second when con- 
verting to PAL, everything which occurs on the TV 
screen takes place 4% faster in Europe than it does In 
the United States.) Whether the frames are processed 
at the rate of 25 per second or 24 per second Is control- 

25 (ed by changing the frequency of the MASTER CLOCK 
signal on bus 85. 

[0037] The output of block 89 Is digital, and Is extend- 
ed to sync generator and D/A converter 92, It Is in this 
element that appropriate sync pulses are inserted into 
30 the fields, and the digital information is converted to an- 
alog. Any subtitles that are required are contained In 
buffer 59. Under control of microprocessor 41, com- 
mands are issued over control lead 97 to graphics gen- 
erator 73. This conventional circuit retrieves coded char- 
as acter information from the subtitle buffer, and generates 
a VIDEO signal on conductor 99 which depicts the sub- 
titles. The KEY signal Is generated on conductor 98, and- 
the two signals are extended to a conventional keyer 
circuit 96. This device merges the subtitles with the vld- 
40 so image (utilizing hard or linear keying at the manufac- 
turer's option, as Is known In the art), and extends the 
composite video signal to a conventional TV display de- 
vice 94. 

45 Lead-in Track Fields 

[0038] Before proceeding with a description of the de- 
tailed processing, it will be helpful to consider the infor- 
mation which is stored in the leaden portion of the disk 

so track. This information Is stored in Individual fields as 
depicted in FIG. 3, and It is this information which con- 
trols subsequent processing of the data read from the 
disk. The format of a data block is shown in FIG. 4, but 
for an understanding of how the data in this block Is 

55 used, it is necessary to appreciate the set-up Informa- 
tion which Is read first 

[0039] Referring to FIG. 3, at the start of the track 
there are a number of lead-in sync bits. Although for all 
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other entries minimum and maximum numbers of bits 
are depicted in the appropriate columns, no such num- 
bers are provided for the lead-In sync bits. The number 
of sync bits required at the beginning of the track de- 
pends on the hardware employed. Given the particular 
hardware and range of disk speeds Involved, a sufficient 
number of sync bits are provided at the start of the track 
to allow the circuits involved with reading the disk, in- 
cluding disk drive controller 27 and block number/point- 
er analyzer 

47, to synchronize themselves to the bit stream on DATA 
OUT conductor 25. Bit synchronization Is a technique 
well known in digital systems. 
[0040] The second field consists of 40 bits represent- 
ing authorized territories. There are several ways in 
which software publishers can lock out play of their soft- 
ware. The most important Involve controlling whether R- 
rated motion pictures can be played (the parental lock 
out option), and whether the final analog output video 
signal can assume the standard selected by the user. It 
is in this way, for example, that a software publisher 
might allow a motion picture to be played on an NTSC 
receiver but not a PAL receiver. But as long as the player 
is provided with this kind of lock out control, it can be 
extended to territories. AH players used with the disks of 
the Invention conform to the same set of specifications. 
One feature of the design is that each player Is provided 
with a representation of the territory or territories for 
which it has been intended for sale. For example, the 
territory or territories can be represented by the settings 
of a DIP switch, a code stored in a microprocessor ROM 
(e.g., in master controller 41) or the like. It is assumed 
that there are a total of 40 possible territories. Each disk 
has a 40-bit field in its lead-in section, each bit of which 
is associated with one of the 40 territories. A 1 in any bit 
position is an indication that the disk is authorized for 
play in the respective territory, and a 0 Is an Indication 
that It Is not. A player whose code Indicates that it is for 
sale In China, for example, will not play a disk If there is 
a 0 in the 40-bit territory field at the position associated 
with China. 

[0041] As an example of the use of such a feature, 
consider a player Intended for sale in a particular coun- 
try. A software publisher might put out a motion picture 
film which for contractual reasons is not to be released 
In that country. It is for this reason that a 0 would be 
stored in the bit position associated with that country in 
the authorized territories field of the lead-in section of 
the track. Upon sensing this bit, master controller 41 
would cause circuit 47 to generate an Inhibit signal on 
conductor 75 which would permanently cause gate 61 
to block all data from passing through it. 
[0042] The third field is a single bit, a flag which Indi- 
cates whether there is any information in the following 
field. This information Is termed herein "special soft- 
ware." The player of FIG. 2 ordinarily executes the same 
software code, typically contained In read-only memory.. 
It is this code which will be described in connection with 



the flowcharts of the drawing. However, since the player 
is microprocessor controlled, there is no reason why it 
cannot be used forsome even totally unrelated purpose, 
and this can be enabted simply by loading software from 

s the disk. If the special software flag is a 1 , then master 
controller 41 reads on conductor 77 the software which 
Immediate follows In field 4. Thus depending on whether 
the special software flag is a 0 or a 1 , the fourth field is 
either empty or contains software of undetermined 

to length. At the end of the software there is a sync word 
which Is unique in the sense that this word is not allowed 
to occur anywhere In the overall data stream. When the 
sync word pattern appears, it is an indication that the 
preceding data field has come to an end, and a new field 

f5 follows, (in the event data having the sync word pattern 
would otherwise appear In the data stream and be mis- 
interpreted as a sync word, it can be avoided using 
known techniques. For example, if the sync word con- 
sists of 32 bits of a predetermined pattern, and some 

so overall data sequence includes this pattern within it, 
then after 31 bits of the data pattern are recorded, an 
extra bit, having a value opposite that of the last bit in 
the sync word pattern, may be inserted In the bit stream. 
When the player sees this bit, it discards it and treats 

25 the following bit as a data bit Instead of the last bit of the 
sync word.) 

[0043] An example of special software might be soft- 
ware for controlling video games. While the player is 
provided with an operating system designed for the play 

30 of motion pictures and multi-track audios, it is certainly 
feasible for the player to perform additional and/or dif- 
ferent functions involved in the play of video games. This 
is especially true if the user interface is detachable and 
joysticks and the like may be connected in place of a 

35 keyboard to accommodate game-playing peripheral 
equipment. The system can be converted to a video 
game player simply by storing the necessary software 
as it Is read from the disk. While In the flowcharts to be 
described below the special software is shown as being 

40 self-contained and not involving the standard process- 
ing steps, the special software can certainly call operat- 
ing system subroutines for execution in order to take ad- 
vantage of the built-in code. 

[0044] The fifth field consists of 12 bit positions, each 
45 corresponding to a different standard. Standards in- 
clude 1250-line European HDTV, 1125-line Japanese 
HDTV, 1050-line proposed American HDTV (as well as 
1080-line and 787-llne proposed standards), 625-line 
PAL, 525-line NTSC, 625-line SEC AM, 360-line "letter 
so box", etc. It is even possible to accommodate future 
standards, although to form an appropriate video signal 
in such a case different software would be required. 
However, that simply entails providing software on a 
disk to supplement the built-in operating system. 
55 [0045] As a single example, if the first bit position of 
the 12-bit field corresponds to the NTSC standard, and 
if the user selects an NTSC standard for play on his TV 
receiver, or if that Is his default setting (as will be dis- 
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cussed below), then an NTSC signal will be generated 
only If the first bit In the authorized standards field is a 1 . 
[0046] Field 6 always contains 100 bits. These bits 
represent respective audio languages - dialog ~ for a 
motion picture. It is rare that so many foreign-language 
versions of the same motion picture will be prepared, 
and it is not contemplated that so many versions will ac- 
tually be included on a disk. In fact, there are a maximum 
of 16 audio tracks which can contain dialog In different 
languages. Each of the 100 bits, except the first, repre- 
sents one of 99 languages. If there Is a 1 in the corre- 
sponding bit position, it is an Indication that there is an 
audio track with dialog in the corresponding language. 
[0047] The first of the 1 00 bit positions does not really 
correspond with a language. Instead, a 1 in the first bit 
position means that there is a music and effects ("M&E") 
track. (By "effects 0 is meant such things as the sound 
associated with thunder, gunshots and the like.) As in- 
dicated in the Comments field on FIG. 3, there are N 
Ts in field 6 of the lead-in section of the overall track, 
where N has a maximum value of 16 (one M&E track 
and up to 1 5 dialog tracks, or up to 1 6 dialog tracks with- 
out M&E). As a single example, suppose that the third 
bit position corresponds with French, the fifth corre- 
sponds with Greek, and the 1 00-blt field is 10101000.... 
0. This means that there is an M&E track, as well as 
French and Greek dialog tracks. It does not mean that 
every single data block on the disk includes bit informa- 
tion which represents M&E, and French and Greek dia- 
log. What it does mean is that any data block has at most 
three audio tracks with M&E and/or dialog. It also means 
that any data block which has such audio track informa- 
tion contains the information in the order M&E, French, 
Greek. Just how the system determines which specific 
data blocks contain audio information forthose languag- 
es represented in the 100-bit field will be described be- 
low In connection with the fields contained in a data 
block. 

[0048] It should be understood that the language au- 
dio tracks do not necessarily Include Just dialog. As will 
be described shortly, it Is possible to mix an M&E track 
with a French dialog track, with the result being a com- 
plete audio track suitable for play In France. But it is cer- 
tainly possible that a particular audio track will include 
pre-rhixed M&E and original dialog. For example, if bit 
position 1 0 of the 1 00-bit field represents English dialog 
and there is a 1 stored there, it means that there is an 
English language version of audio on the disk. However, 
It is possible that in the corresponding audio track there 
is not only English dialog, but a full sound track including 
the M&E. At the same time, there may be M&E in a sep- 
arate track, If there Is a 1 In the first bit position of the 
100-bit field. How the various tracks are processed in 
order to derive a complete sound track for play In any 
given language depends on subsequent Information. 
Field 6 simply represents which audio languages are 
available, as well as whether there is a separate M&E 
track (without any dialog). There is another piece of In- 



. formation which is necessary in order for trie audio 
scheme to function, and that information is represented 
in field 7. For each of the N available audio language 
tracks (up to a maximum of 16), there is a 3-bit code in 

5 the seventh field. Before describing the meaning of the 
codes, it must be understood how the codes are asso- 
ciated with particular tracks and languages. Suppose 
that field 6 Is 101 01 00001 00...0 which is interpreted to 
mean thatthere is an M&E track, a French track, a Greek 

10 track and an English track. From this Information alone, 
there Is no way to tell whether there is even any M&E in 
the French, Greek and English tracks. All that is known 
language-wise is that dialog is available in only three 
languages. For this example,' there would be 12 bits in 

15 field 7. The first three bits are associated with the M&E 
track, the second three bits are associated with the 
French track, and the third and fourth 3-bit codes are 
associated with the Greek and English tracks respec- 
tively. The 3-bit codes are as follows: 

20 

000 - mixing master (M&E) 

001 -- switching master (M&E) 

01 0 - dialog + (M&E), complete audio track 

011 -- track to be mixed with mixing master 

25 1 oo - track to be switched with switching master 

These five codes are ail that are necessary to form com- 
plete sound tracks in the three available languages, 
French, Greek and English. How the tracks are corn- 
so bined will be described below, but what should be borne 
in mind is that the purpose of the entire arrangement is 
to provide sound tracks in many languages (up to 15), 
without requiring what might be a 2-hour audio recording 
for each. In fact, if a movie is two hours long, but the 
35 actual dialog is only 30 minutes, the goal is to record 
one full track (M&E or original sound track), with only a 
30-mlnute audio recording of dialog for a particular lan- 
guage. 

[0049] Field 8 contains Nx4 bits, that is, 4 bits for each 

40 of the N "1 "s in field 6. There is thus a 4-bit code In field 
8 for each audio language track which Is available on 
the disk. The 4-bit code represents the track type, and 
there are a maximum of sixteen possibilities. Typical 
track types are single-channel mono, two-channel Dol- 

45 by, 5.1 -channel Musicam, etc. [The term 5.1 -channel re- 
fers to left, right, center, left rear and right rear channels, 
togetherwith a sub-woofer channel.] The 4-bit track type 
codes allow the master controller to determine the man- 
ner in which audio processor decoder 71 operates on 

so the data in the up-to-16 audio tracks to derive analog 
outputs for speaker system 91 . 
[0050] Considering again field 7, there are several 
ways in which a complete sound track, in a selected lan- 
guage, can be derived from the disk. The operation of 

55 mixing involves mixing (adding together) two sound 
tracks. The operation of switching Involves switching be- 
tween two sound tracks, and playing only one of them 
at any given time. The first track Is always M&E, if it is 
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available. The code for this track is always 000 or 001 . 
If the code Is 000, it means that there is no dialog in the 
track and its M&E is to be mixed with the selected lan- 
guage track. If the code 011 is associated with the 
French track, for example, it means that the first and 
third tracks should be mixed at all times. The dialog, 
when there is dialog, appears in the French track, and 
mixing it with the mixing master provides a complete 
French sound track. On the other hand, the first track 
may be a switching master. What this means is that mu- 
sic and effects are recorded in this track, with or without 
dialog. The French track In this case would be repre- 
sented by a 100 code. It contains M&E and dialog, but 
oniy when there is dialog. The M&E track, the first, is 
played alone when there is no dialog, but the fifth track 
is played alone when there is. The tracks are switched, 
not mixed. The French track, when dialog is recorded in 
it, includes, not only dialog but M&E as well since this 
would be the only source of M&E in a switched type op- 
eration. 

[0051] The fifth possibility (010) is that a particular 
track happens to contain the original sound track, M&E 
togetherwith dialog in the original language, if the dialog 
is in the selected language, the track can be played from 
beginning to end, by itself. This track can also serve as 
a switching master (code 001) for other languages. 
[0052] When it comes to mixing tracks, whatever au- 
di os are in the two specified tracks (the mixing master 
and the track which is mixed with ft) are simply added 
together at all times; whatever audio there is in the two 
tracks gets played. It is' only when switching between 
the switching master and the track with which it is 
switched that one track gets played in lieu of the other. 
It is true that each track may contain audio information 
only when the other does not (which would allow mix- 
ing), but it is conceivable that the switching master will 
also Include dialog, I.e., if it is a recording of the original 
sound track of the motion picture. That is why switching 
is employed - only one track is heard from at any given 
moment As will be described below, each data block in- 
cludes bits which inform the master controller which au- 
dio tracks actually contain data In that block. If a selected 
audio language track with an original 1 00 track code has 
data in any data block, then the audio processor decod- 
er 71 processes the data in that audio track to the ex- 
clusion of any data which might be in the switching mas- 
ter track. Field 9 on FIG. 3 contains six bits which are 
coded to represent a number M, This is the number of 
"other" audio tracks, separate and apart from the up-to- 
1 6 audio language tracks. The usual use for these tracks 
is to represent, In compressed digital form, individual in- 
struments or mixes of instruments, with the user having 
the option of combining them. In an extreme form, there 
could be 63 separate instrumental tracks, with the user 
being able to combine any tracks he desires, and to set 
their relative levels before mixing. If one of the tracks 
contains the combined sound to begin with, It is possible 
to delete an instrument from the orchestral mix by spec- 



ifying that its information content should be deleted, or 
subtracted, from the orchestral mix. This would allow a 
user, for example, to play his piano to the accompani- 
ment of an orchestra playing a concerto from which pi- 

5 ano play has been eliminated, it would also allow a user 
to single out a particular instrument to facilitate practice. 
Precisely what the user does with the "other" audio 
tracks Is determined by menu selections which are 
made available to him. Field 8 simply Identifies how 

10 many "other" audio tracks are present on the disk. (The 
term "other" audio tracks would appearto be rather non- 
descriptive, but this Isnt the case. The intent Is that the 
term subsume any audio track usage other than the pro- 
vision of sound tracks for motion pictures. Rather than 

15 to have orchestral music in these "other" audio tracks, 
for example, it is possible to have individual vocalists, 
allowing a user to study different harmonizations,) 
[0053] It is apparent that if there are indeed 63 "other" 
audio tracks, then much if not most of the disk capacity 

20 may be allocated to audio data. But that is precisely why 
so many audio tracks are made available. It is certainly 
contemplated that some disks playable in the system of 
FIG. 2 will not include video. In fact, field 19, to be de- 
scribed below, is a 1-bit field which informs the master 

25 controller whether there Is any video data at all on the 
disk. 

[0054] Once It is determined that there are M "other" 
audio tracks, the next field specifies how each track is 
coded. As in the case of field 8, a 4-bit code is used for 

30 each of the "other" audio tracks. Thus the number of bits 
in field 10 can be as low as 0 (if there are no "other" 
audio tracks) or as high as 252 (63 x 4). 
[0055] While the player can determine from reading 
fields 9 and 1 0 how many "other" audio tracks there are, 

35 the user has to be told what Is in these tracks in order 
that he know what to do with them. There is a description 
of each track, and it is in multiple languages. The first 
thing that the player must be given is a list of the lan- 
guages in which there are descriptions of the "other" au- 

40 dio tracks. A 100-bit field Is used for this purpose. As 
Indicated in FIG. 3, field 11 has 100 bits. A 1 in any bit 
position is an Indication that track definitions are avail- 
able in the respective language. The correspondence 
between bit positions and languages is the same In field 

« 11 as it-is in field 6. it will be recalled that the first bit 
position in field 6 corresponds to M&E, not a traditional 
"language". The first bit position in field 11 Is thus not 
used, and there can be at most 99 Ts in field 11 . 
[0056] Before the track definitions are actually read 

so and processed, the player must determine what menu 
choices to provide the user. Suppose, for example, that 
there are ten "other" audio tracks, each having sounds 
of different orchestral instruments. Once the track defi- 
nitions in the selected language are made available to 

55 the operating system, it can display a standard menu to 
the user. The user can then pick particular tracks to be 
played together, particular tracks to be deleted, their rel- 
ative sound levels, and other "standard" choices. How- 
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ever, in case the "other" audio tracks do not represent 
orchestral music, or they do represent it but in a way 
that requires unusual menu selections, the standard op- 
erating system software for interfacing with the user so 
that the system can determine what Is to be done with 
the "other" audio tracks will not suffice. To accommodate 
unusual situations, the operating system must be pro- 
vided with special software for the creation of the menu, 
as well as to control how the selected tracks are mixed/ 
deleted following user selections. The technique used 
is the same as the technique described above in con- 
nection with loading special software for changing the 
overall operation of the player (fields 3 and 4). Field 12 
is a single bit. If it is a 1 , it is an indication that there is 
a field 1 3 which contains special mixing/deletion soft- 
ware. As indicated on FIG. 3, field 1 3 thus has anywhere 
from no bits to an undetermined number which is de- 
pendent on the length of the special software to be load- 
ed into the machine from the disk. The special software 
ends with a sync word so that the player will know when 
the next field begins. 

[0057] The next field, field 14, consists of the track 
definitions themselves. Since there are M "other" audio 
tracks, and there are P languages in which they are to 
be defined for the user, PxM character strings are rep- 
resented in field 14. Each string is separated from the 
next by an escape character. First there are M character 
strings (track definitions) in the first language corre- 
sponding to the first position in field 11 which contains 
a 1 , then there are M character strings in the second 
language corresponding to the second bit position in 
field 11 which contains a 1 , etc. As will be described be- 
low, the user informs the player in which of the available 
languages the menu which includes the track definitions 
should be displayed. While the entire DATA OUT bit 
stream from the disk drive Is extended to the master con- 
troller In the system of FIG. 2, only the character strings 
corresponding to the selected language are processed. 
They are processed and displayed In accordance with 
the standard software, or the special mixing/deletion 
software which was just read from field 12 If such soft- 
ware is included on the disk. (It should be noted that it 
is the function of demultiplexer 63 to distribute to the 
several buffers only the respective data bits that are In- 
tended for them. It Is controller 41 that tells the demul- 
tiplexer what to do after the controller interprets the in- 
formation in both the lead-in track section and the indi- 
vidual data blocks.) 

[0058] As described in counection with FIG. 2, provi- 
sion is made for the insertion of subtitles. The language 
is selected by the user as will be described, but the play- 
er must be told the languages in which subtitles are 
available. Another 1 00-bit field is used for this purpose. 
As indicated in line 1 5 of FIG. 3, the "1 "s in the field rep- 
resent the individual languages available for subtitles. 
As is the case with the available display languages, 
there is a maximum of 99 since the first bit position cor- 
responds to M&E which is not strictly speaking a "lan- 



guage." 

[0059] Field 16 is a 4-bit multiple version code. The 
player is informed not only whether there are two ver- 
sions of the same video presentation on the disk, but 

5 also what the ch oices are with respect to them. The first 
bit is a 0 if there is only one version on the disk, in which 
case the second and fourth bits are Ignored. Bit 1 has a 
value of 1 if there are two versions on the disk, The sec- 
ond bit in the code tells the player whether the parental 

10 lock option Is to be Implemented, or whether a different 
criterion is to be used In selecting which version is 
played. The usual situation is where the parental lock 
option is implemented, in which case the bit in the sec- 
ond position of the 4-blt code is a 0. This informs the 

15 playerthat it should determine whetherthe parental lock 
option is "on." If It is, R-rated (or, more broadly, adult- 
rated) versions should not be played. The bit in position 
3 of the code is an indication whether version A (the first 
or only version) is R-rated or not (0 = no, 1 = yes), and 

20 the fourth bit In the code provides the same information 
for version B if there are two versions; if there is only 
one version, the fourth bit is Ignored. This is all the in- 
formation the player needs to determine whether either 
or both of two versions can be played. When there are 

25 two versions of the same motion picture on the disk, the 
user is asked to select one of them. But if the parental 
lock option Is "on" and one of the two versions is R-rated, 
the user Is given only the choice of playing the non-adult 
version, or playing neither, as will be described below. 

30 jf both versions are R-rated and the parental lock option 
is "on", then the user can watch neither version. 
[0060] On the other hand, it is possible that there will 
be two versions of the same material on the disk, but it 
Is not a question of one of them being adult-rated and 

35 the other not For example, one version might be a teach- 
ing film including questions and answers, and the other 
might involve a test on the same subject matter including 
Just questions. For the most part the two versions would 
be the same. In such a case, the first bit In field 1 6 would 

40 still be a 1 to indicate that two versions are available, 
but the second bit would now be a 1 instead of a 0, to 
indicate that the choice between the two versions does 
not depend on whether they are R-rated or not A 1 in 
the second bit position Is an indication that the third and 

45 fourth bits characterize the two. versions respectively 
with respect to a characteristic other than rating. 
[0061] What the third and fourth bits actually mean In 
this case, and what menu choices are provided the user, 
has to be determined by resorting to different criteria. 

50 The same technique that was used twice previously is 
now used once again special software is provided 
along with the version codes. Field 1 7 consists of a sin- 
gle bit which serves as a flag to indicate whether special 
version software is available. If the bit is a 1 , then field 

55 1 8 Is read to access the software. As in the case of the 
two earlier software fields, field 1 8 terminates with a 
sync word to Indicate the start of the next field. The spe- 
cial software controls a menu presentation that is unique 
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for the particular disk. 

[0062] The next field consists of a single bit As indi- 
cated in FIG. 3, it informs the player whether video data 
is available. If it isn't, it simply means that there are no 
video data block fields in the overall data blocks to be 
. described in connection with FIG. 4. 
[0063] Reid 20 is a single bit, and it Identifies the base 
or master aspect ratio, if the bit has a value of 0, it is an 
indication that any video on the disk has a 16:9 "wide 
screen" aspect ratio, as depicted in FIG. 9. On the other 
hand, if the bit is a 1, it is an indication that the aspect 
ratio of the video on the disk Is 4:3. 
[0064] As described above, if the original video has a 
"wide screen" aspect ratio, then there are two ways in 
which a 4:3 reduced aspect ratio can be derived. One 
way is to form the video image from the middle part of 
the "wide screen" original. Another way is to "pan scan" 
in the sense that the section of the original Image which 
is actually utilized is not necessarily always the middle 
part. In fact, FIG. 9 shows the use of more information 
on the left than on the right of the original Image. Field 
21 is a single bit which is Indicative of pan scan availa- 
bility. If field 20 is a 1 , the base aspect ratio Is 4:3 so that 
pan scan availability is irrelevant - the single bit In field 
21 Is simply Ignored. But if the base aspect ratio Is 16: 
9 (field 20 has a 0), the value of the bit in field 21 tells 
the player whether the subsequent data blocks provide 
starting column Information which can be loaded into 
pan scan buffer 57 on FIG. 2. If the bit In field 21 is a 0, 
the data blocks do not include column number Informa- 
tion, and if the video is to be played in a 4:3 aspect ratio 
from a "wide screen" original, then the video image is 
formed from the middle part of each original frame. On 
the other hand, if pan scan information is available in 
the data blocks, then buffer 57 on FIG. 2 is updated as 
required and the final video formed will have an added 
degree of variability. 

[0065] Field 22 Is a 20-blt number which represents 
the total number of data blocks on the disk. However, If 
there are two different versions, while they have many 
data blocks In common, the remaining numbers of 
blocks In the two versions may be different. For exam- 
ple, a scene might be completely omitted from one of 
the versions, in which case it would have a smaller total 
number of data blocks. For this reason, if field 1 6 indi- 
cates that there are two versions of a motion picture or 
other source material on the disk, field 23 provides the 
total number of data blocks in version A, and field 24 
provides the total number of data blocks in version B. 
Both fields are omitted if there is only one version on the 
disk. 

[0066] Each data block may include video Information 
for a variable number of frames. The system could de- 
termine the total playing time from the number of data 
blocks (either the total number if there is only a single 
version, or two different numbers If there are two ver- 
sions), only If the system is Informed of the original frame 
rate and the average number of frames represented in 



each block for the disk as a whole. Two disks with the 
same number of data blocks will have different running 
times if the original source material for one of them was 
motion picture film whose frames were generated at the 

5 rate of 24 per second and the other had an original 
source material derived from a 30 frame-per-second 
video camera. Field 25 is a 4-bit value that Identifies the 
original frame rate (24, 30, etc.), a number necessary 
for proper generation of the video signal. Although the 

10 time represented by each data block could be deter- 
mined from the frame rate If each data block contains 
only one frame, It is possible to store more or less than 
one frame of data in each data block. Also, there may 
be no frame information at all, i.e., the video availability 

15 flag in field 1 9 may be 0. Consequently, field 26 is pro- 
vided. This field contains a 1 0-bit number which repre- 
sents the block time factor, i.e., the average time dura- 
tion represented by each block. Multiplication of the 
block time factor by the total number of blocks (or the 

20 total number in a particular version) yields the running 
time. (In practice, the block time factor is about the same 
for both versions on a disk. If desired, individual block 
time factors can be provided.) 
[0067] As is common practice with optical disks in 

25 general, the disk of the Invention may be provided with 
a table of contents for allowing the user to select a par- 
ticular part to play, or simply to Inform the user of pre- 
cisely what is on the disk and how long each part takes 
to play. Field 27, if included, is a table of contents. If only 

30 one version of the source material is on the disk, then 
there is only one table of contents. Otherwise, there is 
an additional field 28 which consists of the table of con- 
tents for the second version. FIG. 3 sets forth the sub- 
fields in field 27. 

35 [0068] For lack of a better term, the video presentation 
is divided up into what are called "chapters." For each 
chapter the table of contents Includes an 8-blt chapter 
number, thus allowing a maximum of 255 individual 
chapters. Following each chapter number there Is a 

40 20-bit starting block serial block number. It will be re- 
called that all of the data blocks on the disk are num- 
bered serially. In other words, while data blocks may be 
common to both versions A and B, or unique to only one 
of them, the numbers of the data blocks are in serial or- 

45 der along the disk track. The table of contents Includes 
the serial block number of the data block which is the 
starting block for each chapter. 
[0069] Similarly, in order to determine the play time 
for each chapter, the system must know how many 

so blocks are Included in each chapter. For this reason, the 
next piece of information is a 20-bit block duration. Mul- 
tiplying this number by the block time factor allows the 
play time of each chapter to be determined. Alternative- 
ly, the actual running time for each chapter could be pre- 
ss vlded instead of the block duration. (Such information 
could be provided for different versions and standards.) 
[0070] In order to display the title of each chapter, lan- 
guage strings must be provided. Once again, the system 
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must be advised of the languages which are available 
for displaying chapter titles so that the user might select 
one of them. The usual technique of providing a 1 00-bit 
block for identifying available languages is employed. 
Finally, the actual language strings for identifying indi- 
vidual chapters are provided. Each string ends with an 
escape character to separate it from the next string. This 
. Is the same technique used in connection with the "oth- 
er" audio track definitions discussed above in connec- 
tion with field 14. 

[0071] Field 29 has a minimum of 1 00 bits and a max- 
imum of 1200 bits. It will be recalled that there can be 
up to 1 2 authorized standards, i.e., the final video output 
can be in up to 12 different formats. In order to insure 
conformance with quality standards agreed upon by all 
manufacturers of players and all software publishers 
who have agreed to support a common set of specifica- 
tions, it is possible to prevent unauthorized software 
publishers from publishing disks which will play on play- 
ers of the invention. Moreover, it is possible to limit par- 
ticular publishers to the manufacture of disks which will 
play according to only a sub-set of the 1 2 standards. For 
example, If royalties are to be paid on each disk which 
is manufactured according to the agreed-upon specifi- 
cations, and the royalties vary In accordance with the 
number of standards according to which a disk can be 
played, It Is possible to limit certain software manufac- 
turers to only the sub-set of standards for which they 
have agreed to pay. For this reason, there Is an encrypt- 
ed authorization code for each standard; the codes are 
all stored in field 29. The disk will play according to a 
particular standard only if the proper encrypted author- 
ization code is contained on the disk. Field 29 includes 
100 bits for each of the standards authorized in field 5. 
Since at least one standard must be authorized there 
are at least 100 bits. The maximum number of bits is 
1200 if all 12 standards are authorized. 
[0072] The encryption scheme Is based upon the prin- 
ciples of public-key cryptography. Public-key cryptogra- 
phy Is by now well known, and a particularly clear expo- 
sition of the subject is to be found In the August 1 979 
Issue of Scientific American, In an article by Hellman en- 
titled The Mathematics of Public-Key Cryptography." 
The use of a public-key cryptosystem allows a message 
to be encrypted at site A in accordance with a secret 
key, transmitted to site B, and decrypted at site B In ac- 
cordance with a public key. The secret key for encrypting 
the message Is known only to the transmitter. Such a 
scheme is typically used to authenticate a message. Up- 
on decryption of the transmitted encrypted message at 
the receiving site, the message will be Intelligible only if 
it was encrypted with the paired private key. And since 
the private key is private, if the decrypted message is 
Intelligible, it must have originated with the owner of the 
private key. 

[0073] Public-key cryptography Is used in the Inven- 
tion In the following way. The actual data on the track is 
processed by the software publisher In accordance with 



a predetermined algorithm. The details of the process- 
ing are not important. Any non-trivial processing that 
provides, for example, a 1 00-bit result based on the disk 
data will suffice. The 1 00-bit result Is a "message" to be 

5 transmitted via the disk in anywhere from one to twelve 
encrypted forms. There are 1 2 cryptosystem key pairs, 
each associated with a different one of the standards. 
The private key for the first standard authorized on the 
disk is used to encrypt the 1 00-bit message and the 

10 1 oo-bit encryption is stored in field 29. This encryption 
Is the authorization code forthe particular standard. The 
same thing is done for all of the other standards author- 
ized forthe particular disk, with the private key associ- 
ated with each of these standards being used in each 

f5 case. 

[0074] The player operating system computes the 
same 1 00~bit result or message that was originally com- 
puted by the software publisher. The player software 
then uses the public key associated with each of the 

20 standards authorized on the disk to decrypt the respec- 
tive encrypted authorization code for that standard. The 
decrypted message should match the message com- 
puted by the operating system after processing the disk 
data. If they do not match, it Is an indication that the soft- 

25 ware publisher did not have the private key for encrypt- 
ing the authorization code for the particular standard, 
and the player will not produce a video signal according 
to that standard. 

[0075] To explain this in another way, let It be as- 

30 sumed that the private key for authorized standard N on 
the disk gives rise to an encrypted message Pri N (X), 
where X is a message to be encrypted. Similarly, the 
function Pub N (X) represents the decryption of afunction 
X using a paired public key. Let it further be assumed 

35 that the predetermined algorithm for processing the data 
on the disk is known by all player manufacturers and 
software publishers, and gives rise to a 100-bit result 
which Is treated as a "message" M whose content (val- 
ue) depends on the disk data. For standard N, the soft- 

40 ware publisher, afterflrst deriving M, stores on the disk 
the 100-bit encrypted authorization code Pri N (M). The 
player first derives the value M In the same way that the 
software publisher did. The player software then uses 
the public key associated with standard N for decrypting 

45 the encrypted authorization code. The operating system 
thus derives Pub N (Pri N (M)). Since decryption of an en- 
crypted message should result in the original message, 
the result of this decryption should be the same value 
M which the operating system derives by processing the 

50 disk data. If it is, then the particular standard is not only 
authorized, but the publisher has the right to authorize 
It. On the other hand, if the decryption of the encrypted 
authorization code M does not match the algorithmic re- 
sult M derived by the player (because the software pub- 

55 Usher did not have the private key with which to derive 
Prl N (M)), then that particular standard Is locked out. 
[0076] While such a scheme works In the abstract, 
there is one practical problem which must be overcome. 
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Suppose, for example, that the algorithm used to derive 
the original "message" M involves processing 20 data 
blocks on the disk with predetermined serial block num- 
bers. (The processing might be something as simple as 
multiplying by each other successive groups of 100 bits 
each, and using as the result of each multiplication - for 
the next multiplication - only the 1 00 least significant 
bits.) A publisher who is not empowered to authorize 
standard N on a disk may nevertheless wish to do so. 
He does not know the private key with which to encrypt 
the derived value M which is applicable to his software. 
Consequently, he does not know what 1 00-bit encrypted 
code he should put on the disk which will decrypt in a 
player to the value M. But what he can do is copy the 
20 predetermined data blocks from some other legiti- 
mate disk and put them on his own disk, and also copy 
the encrypted authorization code in field 29. Those 20 
data blocks, when processed in a player, will result in 
the value M, and it will match the "stolen 0 encrypted au- 
thorization code after it is decrypted in the player. Of 
course, the software publisher may have committed 
copyright Infringement, but that simply compounds the 
felony. The practical problem which the software pub- 
lisher faces is that he will have data blocks which are 
"played" and which will be totally out of context insofar 
as his motion picture is concerned. However, because 
the way that multiple versions of a motion picture can 
be stored on the same disk in the first place is that the 
player can be controlled to skip over the play of certain 
data blocks, as will be described below, the software 
publisher can encode his other data blocks so that the 
copied data blocks are not played. In this way, the en- 
cryption protection can be rendered ineffective. 
[0077] The solution is that while the algorithm that de- 
rives the "message" M in the first place may also operate 
on predetermined data blocks, it should operate on at 
least the lead-in section of the track. There Is no way 
that an unauthorized publisher can copy the lead-in 
track fields from another disk because that would give 
a player incorrect information about the video and audio 
contents on the unauthorized publisher's disk. The lead- 
in data Is a function of the particular subject matter of 
the disk, and It must appear in the track in order for the 
disk to play properly. Thus the information represented 
on FIG. 3 can be treated as the "message" M whose 
encryptions, one for each authorized standard, are de- 
rived using respective private keys and are stored in 
lead-in field 29. (Strictly speaking, the "message" M is 
the result of processing all fields except field 29. Also, 
the longer fields, such as those containing software, can 
be omitted from the processing.) The player derives the 
same "message", decrypts an encrypted authorization 
code with the public key associated with the respective 
standard, and then compares the two. If they don't 
match, the player determines that that particular stand- 
ard has not been authorized for the particular disk's pub- 
lisher. 

[0078] The encrypted authorization code field is 



shown toward the end of FIG. 3 and thus the corre- 
sponding processing is depicted toward the end of the 
flowchart of FIGS. 5A-5C to be discussed below. The 
positioning of the encrypted authorization code field as 

s shown facilitates a description of its processing, but in 
fact the field may advantageously be placed at the start 
of the processing. It will be recalled that special software 
may be read from the disk to modify the normal player 
sequencing. It Is therefore conceivable that a counter- 

10 feiter could write special software which causes the au- 
thorization code processing to be bypassed. By doing 
the processing before any special software is even read, 
the processing cannot be bypassed. 
[0079] Returning to a description of the lead-in track 

is fields, field 30 is a 1-bit data block command/data flag. 
This bit informs the operating system whether the data 
blocks include command information or data which is to 
be read during play of the disk. How the system deter- 
mines whether a particular data block contains com- 

20 mands or data will be explained below. Field 30 simply 
indicates whether there fs any such Information at all. 
Finally, fields 31 and 32 are catch-all fields for allowing 
the disk to control unusual ways In which the player 
processes the Information on the disk, it will be recalled 

25 that field 3 contains a flag which indicates whether field 
4 contains special software which causes the player to 
operate In accordance with a program that Is totally dif- 
ferent from that usually employed, field 12 Indicates 
whether field 13 contains special mixing/deletion soft- 

30 ware for use with the "other" audio tracks, and field 17 
contains a flag which indicates whether field 1 8 contains 
special version software for processing the 4-bit multiple 
version code. Field 31 indicates whether there is "sup- 
plemental" software in field 32. The supplemental soft- 

35 ware is different from the special software of field 4 in 
that the software in field 4 is basically a substitute for 
the processing which is normally used, while the sup- 
plemental software generally works with that code, in 
conjunction with commands and data which are to be 

40 found in the data blocks. 

[0080] Typically, the supplemental software would al- 
low play of a video game, with related commands and 
data In the data blocks determining the course of play. 
But there are other uses of this technique. As another 

45 example of the way in which supplemental software, and 
commands and data in the data blocks, can be used, 
consider a disk designed to play a classic motion picture 
with subtitles, but which is also provided with a critical 
commentary which Is to be displayed periodically in lieu 

so of subtitles, perhaps during moments when the screen 
is caused to go blank except for the critical commentary. 
To show the flexibility which is possible, let us even con- 
sider a case where the critical commentary is to be in a 
different language. What is required in such a case is 

55 that the subtitle buffer 59 on FIG. 2 be loaded during the 
play of some data blocks with subtitles in one language 
and with subtitles in another language during play of oth- 
er data blocks (some data blocks thus containing subtl- 
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ties corresponding to the original motion picture, and 
others containing critical commentary in another lan- 
guage). In such a case, the system must somehow be 
told to switch back and forth between language subti- 
tles, i.e., different subtitle tracks have to be processed 
In different data blocks. This can be conveniently con- 
trolled by issuing commands In the data blocks them- 
selves. Similarly, If It is desired to blank the screen and 
interrupt the picture during display of commentary, a da- 
ta block might Include a data value which represents the 
duration of the blanking. Alternatively, If a commentary 
is to be made In a different language, It could be a dif- 
ferent audio track which is selected for the purpose. In 
any case, the special software loaded from field 32 
wouid control the processing of the commands and data 
contained in the data blocks, and would work in conjunc- 
tion with the operating system of the player. 

Processing Of The Lead-in Track Fields 

[0081] The flowchart of FIGS. 5A-5E depicts the 
processing of the information In the lead-in track fields. 
A description of this preliminary processing Is presented 
at this point, with the functions of the individual fields In 
mind. The fields in the data blocks, as well as processing 
of the data blocks, are discussed below. 
[0082] The system processing begins, as shown at 
the top of FIG. 5A, with the reading of default settings. 
These are settings established by DIP switches, ROM 
codes, or the use of any other device or technique which 
configures the system on power-up. It is typical in mi- 
croprocessor-based systems to reset all flags and to 
read default settings when power is first turned on. 
[0083] There are four default settings which are thus 
determined in order to configure the system. The first is 
the standard - players sold in the United States, for ex- 
ample, will typically be configured, in the default state, 
to produce an NTSC video signal. 
[0084] The next default setting is language ~ the 
sound track dialog language, the subtitle language (if 
any), and the language in which menus are to be pre- 
sented on the display. In the United States, for example, 
the default language would be English. If the user does 
not Inform the player that a language other than English 
is desired for one or more of these functions, audio lan- 
guage track 1 0 will be used to generate the sound track, 
and. character strings in the English language will be 
used in setting up the mixing/deletion menu for the "oth- 
er" audio tracks and for the table of contents. As for sub- 
titles, the usual default Is "no language." 
[0085] The third default Is the aspect ratio, 4:3 in the 
United States. The aspect ratio determines the relative 
dimensions of the display represented by the final video 
output signal. 

[0086] Finally, the parental lock status Is determined. 
In the system of FIG. 2, this simply entails a determina- 
tion of the setting of lock 81 . But it Is also possible to 
dispense with a physical lock and key, and to store the 



parental lock status in non-volatile memory after first In- 
putting on the keyboard a password known only to the 
persons who exercise control over the lock function. 
[0087] As in many consumer electronic devices, the 

5 keyboard can be used by the user at any time to inter- 
rogate or control the player. Routine control sequences 
which are standard In the art are not shown In the flow- 
charts. For example, the keyboard, or an associated re- 
mote control device, can be used to control the volume, 

10 fast forward, a Jump to a specified chapter, etc. The nor- 
mal processing can be Interrupted to control a display 
by operating a menu key, as Is known In the art. At the 
start of the processing of FIG. 5 A, there is shown a test 
for determining whether the menu key is operated. The 

f5 reason for showing an interrogation of whether the 
menu key is operated at the start of the processing, as 
opposed to any other time during play of the disk, is that 
this is the mechanism by which default settings can be 
changed. If the menu key is operated when power is first 

20 turned on, the system displays a menu. As indicated in 
the flowchart, the user Is given the choice of changing 
defaults, viewing the table of contents for the disk, and/ 
or (In case the menu key was operated accidentally) 
simply returning to the processing without changing an- 

25 ythlng. As Indicated, depending on the menu selection, 
the defaults are changed, the entire menu selection 
process is aborted, or a TOC (table of contents) flag is 
set to 1 . This flag will be examined later to determine 
whether the table of contents should be displayed. 

30 [0088] Thus far, no information from the disk has been 
processed, (in this description, references are some- 
times made to reading a field and sometimes made to 
processing a field. It is to be understood that even when 
it is said that after a certain processing step a field is 

35 read, the field may actually have been read earlier but 
stored In a buffer for later use. Depending on the con- 
text, reading a field means to actually read it so that the 
bits appear on the DATA OUT conductor 25 In FIG. 2, 
or to do something with the data If It has been read ear- 

40 Her and buffered.) Referring to FIG. 3, the first Informa- 
tion field which is read from the lead-in track section is 
a 40-bit field representing authorized territories. Next, a 
check Is made to see whether the territory In which the 
player was intended for use Is one of those authorized 

45 on the disk. The player territory is also a kind of default 
setting, but it is not grouped with the others because it 
cannot be changed by the user. (To allow a purchaser 
who moves from one territory to another to use his play- 
er, the player territory can be changed by an authorized 

so technician.) If the player hBS been designed for use in 
China, for example, and China is not one of the territo- 
ries authorized on the disk, play of the disk is aborted. 
[0089] On the other hand, if the disk has been author- 
ized for play in the player territory, field 3 is read. This 

55 single bit simply tells the system whether special soft- 
ware is present. As shown In the flowchart, If it is present 
then the special software is read from field 4 and exe- 
cuted. The processing terminates with the "execute spe- 



15 



29 



EP 0 971 536 B1 



30 



cial software" step. This is intended to show that the spe- 
cial software in field 4 basically replaces the built-in op- 
erating system. Such software will be employed when a 
radical change in the overall use of the player is in- 
volved. (As mentioned above, this is not to say that the 
special software may not call BIOS routines and the like 
from the ROM chips containing the operating system.) 
[0090] If there Is no special software present, the sys- 
tem reads the default standard, e.g., It determines that 
an NTSC standard is to be employed. If the user has 
changed the default standard through a menu selection, 
e.g., to PAL, then PAL Is the new default standard. The 
system then accesses field 5 which authorizes up to 12 
standards. The test which is performed is to determine 
whether the default standard (the original, or as 
changed at the start of the processing) is authorized. If 
It Is not, a menu Is displayed which shows the user the 
authorized standards, and he then selects one. After an 
appropriate selection is made, or if the default standard 
is authorized, the system processes fields 6 and 7. The 
reading of field 6 Informs the player of the available au- 
dio languages (up to 1 6, including M&E and 1 5 languag- 
es). 

[0091] Once again, a default value is tested against a 
set of allowed options. Earlier, it was the default stand- 
ard that was tested against the authorized standards 
read from the disk. This time it Is the default audio lan- 
guage (eitherthe default language on power-up or a dif- 
ferent language selected by the user If the menu key 
was operated) that is compared with all of those availa- 
ble. As shown in the flowchart, if the default language is 
not available, a display is formed which lists the availa- 
ble audio languages, and the user selects one of them. 
The system then reads the track types In field 7. This Is 
the field which informs the operating system whether 
there is an M&E track, whether it is to be used as a mix- 
ing or a switching master, and.whetherthe selected lan- 
guage track is a complete audio track, Is to be mixed 
with the mixing master, or to be switched with the switch- 
ing master. Next, the track codings are read from field 
8. Given the selected language, and its track type and 
track coding, as well as information about M&E, mixing 
and switching, the operating system has all of the infor- 
mation It needs to generate a sound track for the accom- 
panying motion picture which meets the needs of the 
viewer. 

[0092] The next thing that is done is to read field 9 to 
determine the number of "other 0 audio tracks which are 
on the disk, anywhere from none up to 63. If there are 
indeed no "other" audio tracks, all of the processing to 
determine what is to be done with them is bypassed. But 
if there are such tracks, field 1 0 is first read to determine 
how they are coded. Since the user has to be told what 
Is in the tracks before he can determine what is to be 
done with them, the system must next determine from 
reading field 11 the "other" track menu languages which 
are on the disk. The usual type of check is then made 
to see whether the menu Is available In the default lan- 



guage. If it is not, the available languages are displayed 
and the user selects one of them. 
[0093] As described above, the operating system may 
execute a standard routine for reading the menu, dis- 
s playing it, and interacting with the user as the user de- 
termines what should be done with the "other" audio 
tracks. But in the event special mixing or deletion is to 
be accomplished, special mixing/deletion software is re- 
quired. Field 12 is read to see whether such software is 
10 available and, as indicated in the flowchart, any special 
mixing/deletion software which is on the disk Is read 
from field 13. Only then are the actual menu Items (in 
the selected language) read from field 14 and displayed 
for the user. Using the menus made available by the op- 
ts erating system, the user selects the play mode for the 
"other" audio tracks. He can, for example, mix them in 
any allowed way, use what is in a track for deletion (by 
phase inversion) from another more inclusive track, ad- 
just one track for exclusive play, adjust relative audio 
20 levels, etc., The special mixing/deletion software, of 
course, can provide these options as well as others not 
routinely offered. 

[0094] As shown in FIG. 5B, subtitle information is 
now processed according to the established pattern. 

25 First, the system determines whether subtitles are de- 
sired at all. At the very beginning of the processing in 
FIG. 5A, it will be recalled that one of the default settings 
Is the subtitle language. The usual default setting will be 
that subtitles are not desired. If that Is in fact the case, 

30 the subtitle processing is skipped entirely. But if subtitles 
are desired, the available subtitle languages are read 
from field 15. A test Is then made to see If the default 
subtitle language is available, if it is not, the available 
subtitle languages are displayed and the user selects 

35 one of them. 

[0095] Next, the 4-bit multiple version code in field 1 6 
Is read. The first bit indicates whether there are two ver- 
sions available, or only one. A branch is not made at this 
point because first the system must determine whether 

40 special version software is available, and this Is deter- 
mined from field 17. If special version software Is avail- 
able, It Is read from field 1 8 and executed. To the extent 
that this software must know whether multiple versions 
are available, and what the codes In the third and fourth 

45 bit positions represent, that has already been deter- 
mined. Although indicated in the flowchart that the 
choices displayed for the user are to select among au- 
thorized versions, or to exit, it is to be understood that 
the display choices will generally be different if special 

so version software is executed. Also, it should be under- 
stood that there may be special version software even 
If there Is only one version that can be played. For ex- 
ample, it may be appropriate to warn a viewer that a par- 
ticular program may be extraordinarily unsettling, and to 

ss ask for a "continue" response before play begins - all 
of this "being separate and apart from an R-ratlng. 
[0096] If special version software Is not available, then 
bits 3 and 4 in the 4-bit multiple version code field are 
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used for rating purposes. A test is performed to see 
whether the parental lock is on. If it is not, then there are 
no restrictions on the play of versions A and B, and both 
versions are authorized, if it was previously determined 
that there is only one version, then that version is con- 
sidered to be version A and It is authorized. 
[0097] On the other hand, If the parental lock is on, 
tests must be performed to see whether the versions on 
the disk are R-rated. As shown in FIG. 5C, If version A 
is R-rated, and so is version B, then play of the system 
is aborted; although not shown, an appropriate mes- 
sage may be displayed to advise the user why play has 
stopped. If version A Is R-rated but version B is not, then 
only version B is authorized. On the other hand, if ver- 
sion A is not R-rated but version B is, only version A is 
authorized. Finally, even if the parental lock is on, if nei- 
ther version is R-rated, then both versions are author- 
ized. 

[0098] The system next displays the choices available 
to the user. He can choose from among the authorized 
versions, or he can exit and stop playing the disk. (This 
latter case might arise, for example, if a child tries to 
watch an R-rated version, is told that it cannot be played, 
and a decision Is made to go on to something else more 
interesting.) 

[0099] If there is only one version available, if It is not 
R-rated, and if there is no special version software, then 
there may be no need for a display - there Is only one 
motion picture which can be played, and there are no 
restrictions on who can watch it. Nevertheless, as 
shown in the flowchart, the user is still given a choice 
between play of the disk and aborting play. The system 
could be designed to skip the display in such a case and 
simply to assume that the user wants to watch the only 
motion picture version which is on the disk. On the other 
hand, generating the display allows the user to verify 
that the disk he put in the player is Indeed the disk he 
wants. 

[0100] Although the invention has been described 
thus far In terms of one or two versions of a motion pic- 
ture on a disk, it is to be understood that there can be 
three or more versions. This is one of the main reasons 
for providing the capability of reading special version 
software in the first place. This software can include all 
of the information required about the several versions 
from which menu displays are formed so that the user 
can select what is to be played, As mentioned above, 
the special version software can aliow choices between 
teaching and test modes , and other options having noth- 
ing to do with whether particular motion pictures are 
adult-rated. 

[0101] The system next reads the video availability bit 
in field 11 , and thus determines whether the data blocks 
which will be processed subsequently contain video da- 
ta. If video data is present, then the base or master as- 
pect ratio in which it has been stored on the disk must 
be determined. The next step thus involves reading field 
20 to ascertain whether the base or master aspect ratio 



is 1 6:9 or 4:3. If the master aspect ratio is 4:3, the next 
five steps are skipped because pan scan availability is 
irrelevant. If the default aspect ratio is 4:3, then there is 
a one-to-one correspondence between stored and dis- 

s played frames: if the default aspect ratio is 1 6:9, then a 
4:3 frame Is displayed on a wide screen with a dark band 
at either side. (Alternatively, the 4:3 image could be ex- 
panded to fill the 1 6:9 screen, with resulting loss of top 
and/or bottom Information.) But if the base aspect ratio 

10 is 16:9, as shown on FIG. 9, there are several possibil- 
ities which must be explored. 
[01 02] One of the default values which is determined 
at the very start of the processing is the aspect ratio. 
The operating system checks whether the default as- 

15 pect ratio is pan scan 4:3. Referring to FIG. 9, if the mas- 
ter aspect ratio is "wide screen" (the flowchart branch 
being processed), then the possibilities are letter box, 
pan scan centered on the wide screen Image (not shown 
in FIG. 9), or pan scan variable (i.e. , with a variable start- 

20 ing column number). If the default is not pan scan 4:3, 
then there are no choices to be made by the user now. 
The default is either wide screen or letter box, and sub- 
sequent processing is in accordance with the default 
which has already been determined. 

25 [0103] On the other hand, if the default is pan scan 4: 
3, the issue Is whether variable pan scan information is 
on the disk. The pan scan availability bit in field 21 is 
read. If pan scan is available, it means that the data 
blocks will specify to the operating system the starting 

30 column numbers forthe pan scan - the user need select 
nothing at this point. On the other hand, if pan scan is 
not available, and this was the user's default, he must 
decide from among two possibilities - a center cut, in 
which the middle part of every wide screen frame is dis- 
ss played, or a letter box form in which the entirety of every 
frame can be seen, but the display has dark bands at 
the top and bottom. A menu display is formed, and the 
user selects one of the two modes. 
[01 04] This use of a common aspect ratio on the disk 

*o which nevertheless allows the user to select from many 
different kinds of display exemplifies the design ap- 
proach of the invention. The basic idea Is to provide 
maximum flexibility while nevertheless storing all of the 
required data on an optical disk roughly the size of a 

45 conventional CD. Once a wide screen motion picture is 
stored on the disk, almost no additional real estate is 
required to allow the user to generate a video output 
having some other aspect ratio. Although there may be 
up to 15 languages In which dialog can be heard, there 

so are nowhere near 15 full sound tracks because of the 
mixing and switching capabilities built into the player 
and the manner in which redundant information Is elim- 
inated from the audio language tracks. The same thing 
applies to video standards. While up to now high-quality 

55 video has required a medium which can be played only 
In NTSC, or PAL, etc., the present Invention allows the 
same disk to give rise to video signals In up to 12 stand- 
ards. One of the advantages of the Invention is that It 
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greatly reduces the number of different disks that must 
be produced, for example, by a motion picture company 
that distributes its movies throughout the world. While it 
is true that some fields may have to be changed from 
time to time, for example, different standards have to be 
authorized when videos are released In NTSC and In 
PAL at different times, such changes are relatively trivial 
and are easily made. 

[01 05] Once a decision on the display mode is made, 
field 22 Is read to determine the total number of data 
blocks on the disk. If there are multiple versions, fields 
23 and 24 are also read in order to determine the total 
number of data blocks in each of the versions. Field 25 
is then read to determine the original frame rate, and 
field 26 is read to determine the block time factor. 
[0106] Field 27 is then processed. It will be recalled 
from FIG. 3 that this is the field that contains ail of the 
necessary Information for display of the table of con- 
tents. The table of contents for the selected version (field 
27 if there is only one version, or there are two and the 
first has been selected; or field 28 if there are two ver- 
sions and the second has been selected) includes a 
1 00-bit representation of the available chapter display 
languages. The default menu language is checked 
against those which are available. If the default menu 
language is not available, the user is Informed of those 
languages in which chapter titles can be displayed, and 
he selects from among them. Once It has been deter- 
mined in which language to display chapter Information, 
the various table of contents time durations are calcu- 
lated. Since it is known how many blocks are in each 
chapter, the duration of each chapter can be determined 
by multiplying the number of blocks by the block time 
factor. 

[0107] The table of contents is not necessarily dis- 
played. It is displayed only if the TOC flag was set at the 
start of the processing, the user having indicated that 
the table of contents should be displayed, if the TOC 
flag is 0, there Is no need to display the table of contents. 
The system automatically selects the first data block as 
the starting point, that Is, play of the disk starts at the 
beginning. On the other hand, If the TOC flag is a 1 , the 
table of contents Is displayed and the user is given the 
option of selecting the start point 
[01 08] Following the table or tables of contents on the 
disk are the encrypted authorization codes for the stand- 
ards authorized in field 5. The operating system reads 
the encrypted authorization code for the standard which 
has been selected. It then reads the predetermined data 
for the selected standard. It will be recalled that for each 
of the 1 2 possible standards, predetermined data on the 
disk is processed to derive a "message" M which serves 
as an authorization code. It is this authorization code 
that is stored in encrypted form on the disk using the 
private key associated with each standard. The data 
which is read from the disk may be different for each 
standard, as long as the same data Is read and proc- 
essed both during the encryption process and when the 



player derives the "message" M on its own. As dis- 
cussed above, it is preferred that the data include at 
least part of the lead-in fields because it would be self- 
defeating for an authorized publisher to copy this data. 

s [0109] After the predetermined data for the selected 
standard Is read, the authorization code ("message" M) 
Is computed from the data. Using the public key asso- 
ciated with the selected standard, which key is built Into 
the operating system, the stored authorization code on 

10 the disk for the selected standard Is decrypted. The test 
for whether the software publisher has been authorized 
to publish disks which will play as video signals in the 
selected standard involves comparing the decrypted au- 
thorization code with the computed authorization code. 

*5 If they do not match, play is aborted. 

[01 10] If the two codes do match, field 30 is read. This 
single bit simply informs the master processor whether 
there are any commands or data stored in the data 
blocks other than the normal complement depicted in 

20 FIG. 4 to be discussed below. If the flag is a 0, the op- 
erating system does not even look for such additional 
commands or data in the data blocks. If the flag is a 1 , 
It means that commands or data may be present in a 
data block, but not necessarily so. 

25 [0111] Finally, field 31 is read in order to determine 
whether supplemental software Is available. If It Is, It Is 
read from field 32. The supplemental software, as de- 
scribed above, is not to be used in lieu of the operating 
system software, but rather as a supplement to it. This 

so Is the basic difference between the software in fields 4 
and 32. Generally speaking, the supplemental software 
operates on commands and data included in the data 
blocks in a field whose presence is indicated (although 
not necessarily In every data block, as will become ap- 

35 parent below) by the supplemental software flag. 

[0112] With the reading of field 32 and its integration 
with the operating system, the read head in the disk 
drive is caused to move to the start point. As described 
above, the start point Is either the first data block or a 

40 data block determined by the user if a chapter other than 
the first has been selected. Data blocks are read in se- 
quence and demultiplexer 63 on FIG. 2 distributes the 
data fields to various buffers. As Indicated in the flow- 
chart, the reading of a data block takes place only if no 

45 buffer is full. Furthermore, before a new data block is 
read, the system checks whether there are any inter- 
rupts which must be serviced. Controller 41 is the source 
of all interrupts. For example, if the user has operated 
the keyboard, the controller generates an interrupt on 

so line 43 of FIG. 2 which temporarily halts the reading, of 
data blocks. After the Interrupt has been processed, or 
if there Is no interrupt which must be serviced, the next 
data block is read, As will be described, the serial block 
number is one of the first things that is read. The block 

55 number/pointer analyzer 47 knows the number of the 
next block which Is required. Very often, this will simply 
be the next block In the serial sequence. However, the 
block number may be out of sequence, for example, if 
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a jump Is to be made to a new chapter, or, as will become 
apparent below, certain blocks have to be skipped on a 
disk when playing one of multiple versions of a motion 
picture. In any event, the systems checks whether the 
block being read is the correct one. If it is not, a branch 
is made back to the start of the block reading process 
so that a different block can be read. Also, gate 61 on 
FIG. 2 is closed so that the "wrong" data on conductor 
25 is not extended to demultiplexer 63. 
[0113] If the block read Is the required block, one of 
the first things read Immediately after the block number 
Is pointer data. The pointer data Is used by block 
number/pointer analyzer 47 to determine the block 
number of the next data block that Is required, as Indi- 
cated toward the end of the flowchart This block number 
is transmitted over cable 49 to microprocessor disk drive 
controller 27 in order that it access this data block at the 
completion of the reading of the current data block. As 
indicated at the end of the flowchart, the remainder of 
the data block which is being processed at the moment 
is read and loaded into the several buffers, following 
which another-data block may be read. 
[0114] The flowchart just reviewed controls the 
processing of the player. What is actually done with the 
data read from the data blocks is shown In the flowchart 
of FIG. 6, and this flowchart will be described after the 
fields in a data block, as listed in FIG. 4, are understood. 
But In order to appreciate the function of the pointer data 
which is included in a data block, FIGS. 7A and 73 will 
be described first. These figures depict how data blocks 
associated with individual or both versions of a motion 
picture Interrelate with each other, and how the system 
is controlled to skip over certain data blocks in order to 
play a selected version. 

FIGS. 7A And 7B - The Function Of The Pointer Data 

[0115] In the Illustrative embodiment of the invention, 
there can be two versions of the same motion picture 
on a disk. Most of the data blocks will represent video 
and audio which are common to the two versions. How- 
ever, there will be other blocks that are unique to one 
version or the other. The question is how to control the 
reading In succession of the data blocks that are re- 
quired for a selected one of the two versions. For pur- 
poses of description, the letters A, B and C will be used 
to identify respectively data blocks that are unique to 
version A of the motion picture, data blocks that are 
unique to version B, and data blocks that are common 
to both. FIG. 7B illustrates a portion of the track with 
successive data blocks being labelled A, B or C. It will 
be understood that In practice there may be thousands 
of data blocks In succession of the same type, with most 
of the data blocks on the disk being of type C. However, 
to illustrate the way In which the system Jumps over data 
blocks that are not required, FIG. 7B shows at most two 
blocks of the same type in succession. 
[0116] There are two sequences shown In FIG. 7B, 



one at the top for playing version B, and the other at the 
bottom for playing version A. If it is version B that is se- 
lected, and it is assumed that somehow the B block on 
the left is being played, it is apparent that the next two 

s A blocks must be jumped over in order to go to the fourth 
block, a B block. After this block is played, the next A 
block must be jumped over. Two common C blocks are 
then played, after which a jump must be made over an 
A block to another C. The next block, a B, Is then played, 

10 followed by B, C and B blocks. Finally, a jump Is made 
over an A block to the last block shown In FIG. 7B, a C 
block. 

[0117] If version A Is being played, on the other hand, 
two successive A blocks are played, there Is then a jump 
15 over a B block, the next five blocks - A, C, C, A, C - 
are played, there is next a jump over two B blocks to a 
C block, and finally there is a jump over another B block 
to an A and a following C. 

[0118] The pattern which emerges Is that there are 

20 three kinds of transitions from one block to another. 
First, there Is the play of a block immediately following 
play of the preceding block. There are seven examples 
of this shown In FIG. 7B - AA, BB, CC, CA, CB, AC and 
BC. The two possibilities which are excluded are AB and 

25 BA, since blocks unique to the two versions will never 
be played during the same disk playing, much less one 
after the other. While there are seven kinds of transitions 
from block type to block type, there are really just three 
basic operations - going from one block of any type to 

30 the next block of any type; a jump from either an A to an 
A or C, or from a B to a B or C; or a branch from a C 
block either to an adjacent A or B, or to a B or A some- 
where down the line. Most transitions are of the first 
type. The second type occurs when an A is followed by 

35 a B (which two blocks can never be played in succes- 
sion) ; a jump must be made from the A to either another 
A or to a C. Similar remarks apply to a B followed by an 
A. The third type occurs at the end of the play of a C 
block, when there Is no longer any common material to 

40 be played and a switch must be made to one version or 
the other: the next block Is played If it Is part of the ver- 
sion selected, or some blocks will have to be jumped 
over if the branch Is to a block In the other version. 
[01 1 9] FIG. 7A shows the state diagram which defines 

45 how and when transitions are made from one block to 
another. As will be described below, every data block 
includes a two-bit pointer flag, possibly followed by a 
field which contains a 20-bit pointer. (When a pointer Is 
present, it always points to the serial block number of 

so another data block.) Referring to the code given in FIG. 
7A, if the two-bit pointer flag Is 00, It is an indication that 
the processing should continue with the next block: in 
this case, there is no need for a pointer. If the two-bit 
pointer flag is a 01 code, it is an indication that a Jump 

55 should be made to a block In the same version some 
distance away, or to a C block some distance away. In 
either case, a pointer is necessary. 
[0120] The codes 10 and 11 are used when a branch 
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is to be taken from a common C block. Which code is 
used depends on whether the next block is an A or B. If 
the block after the C is an A, code 1 0 Is used and the 
pointer is to a B or a C further down the line. If the code 
is 1 1 , it means that the next block is a B, and the pointer 
is to an A or a C further along the track. The operating 
system knows which version Is being played, if version 
A is being played and the current block has a 1 0 pointer 
flag, it means that the next block, an A, should be played 
after the present one. There is no need for the pointer. 
The pointer is necessary in case version B is being 
played. In this case, since the next block is an A, it 
should not be played. The player should jump to the 
block identified by the pointer - either another C, or a B 
unique to version B being played. 
[0121] Similarly, if version A is being played and the 
current block is a C with code 1 1 for its pointer flag, it 
means that the next block is a B. Since version A is being 
played, the next block should not be played after the cur- 
rent one. Instead, a jump is made to the A or C block 
Identified by the pointer. On the other hand, if version B 
is being played, the system simply continues to the next 
block. 

[0122] The legend on FIG. 7A shows whether or not 
the pointer Is used when 1 0 and 1 1 pointer flags are 
found in a C block. The representation 10(P) is an Indi- 
cation that the pointer should be used, and a represen- 
tation 10[P] is an Indication that the pointer should be 
ignored, ft will be recalled that the 1 0 code Is used for a 
C block when the next block Is an A. If version A Is being 
played, the pointer is not needed. That is why a transi- 
tion from the C block to the succeeding block, an A, is 
shown by the symbol 1 0[P]. On the other hand, if version 
B Is being played, since the next block is an A it cannot 
be played after the current C. Instead, there must be a 
jump to the block identified by the pointer and thus use 
of the representation 1 0{P) - the pointer points to either 
a B block or another C. 

[0123] Similar remarks apply to the representations 
11 (P) and 1 1[P]. In both cases, it Is a C block which is 
being played and the next block Is a B. If version A is 
being played, the next block should not be played and 
thus the symbol 11 (P) Is required to show a state tran- 
sition. On the other hand, If version B Is being played, it 
is the succeeding B block which should be played, and 
thus the symbol 11 [P] is appropriate. The four codes, as 
well as the usages (P) and [P], are depicted in FIG. 7B. 
Referring to the PLAY B transition sequence, the first 
transition shown Is 01 (P). It will be recalled that the 01 
code represents a jump from one version to a block of 
the same version or to a common block, and a pointer 
Is required. The first transition shown Is 01 (P), a jump 
from a B block to another B block. The next transition 
on the PLAY B line is 01 (P), a jump from a B to a C. Next 
Is an example of the most common transition of all, 00, 
the orderly play of the next block after the current block. 
[0124] The fourth transition in the PLAY B line is rep- 
resented by a 10(P) symbol. The 10 code represents a 



branch from a C block when the next block is an A, the 
example illustrated in FIG. 7B. In such a case, as indi- 
cated In FIG. 7A, if it Is version B which is being played 
a jump is made to the block identified by the pointer - 

5 in this case, the next C. 

[0125] The 11 code is used to identify a branch from 
a C block when the next block is a B. If version B is being 
played, the case under consideration, the pointer is not 
necessary because the next block is to be played. That 

10 Is why the next code shown is 11[P], There follow two 
00 codes that represent obvious transitions to adjacent 
blocks, followed by a 11 [P] code, a branch from a C 
block to the succeeding block which is a B. Finally, a 
jump is made from this B block over the next A block to 

15 a C block. This requires a 01 (P) code — the code used 
to jump from a block of either version to a block of the 
same version or a common block. 
[0126] The PLAY A sequence in FIG. 7B assumes that 
It Is version A that is being played. The first four codes 

20 represent transitions to adjacent blocks, or a jump from 
a block of one version to a block in the same version. 
The next code, 10[P], Is used to show a branch from a 
C block to an adjacent A block. The pointer is not used 
since version A is being played, and code 1 0 is em- 

25 ployed because the next block is an A block. The next 
00 code symbolizes the transition from the A block to a 
succeeding C block. 

[0127] Next is a jump from a C block to another C 
block, skipping over two B blocks. The 11 code is used 

30 because this is the code employed when a B block fol- 
lows a C block. The symbol used is 11 (P), not 11 [P], 
because the pointer is required In going from one C 
block to a C block further down the line. Similarly, the 
next code is again a 11 (P) code to symbolize a branch 

35 from a C block to an A block further down the line. The 
sequence In FIG. 7B ends with a transition from an A 
block to the next block which Is a C, for which the code 
00 Is used. 

. [0128] The state diagram of FIG. 7A summarizes all 
40 possibilities. Consider first the state in which an A block 
is being processed, represented by the circle with an A 
in ft at the upper left The two-bit pointer flag in an A block 
Is 00 if the next block Is also an A (shown by the transi- 
tion from A back to A). If the next block Is a B, on the 
45 other hand, then it clearly should not be played. There 
must be a jump from the A block over the B, either to 
another A or to a C. In either case, the code is 01 (P). 
The drawing shows both a jump over B (to another A), 
and a jump over B-to a C. The only other transition from 
so an A block Is to the next block if It Is a C. This is shown 
by the code 00. 

[0129] There are four similar transitions shown for 
state B, i.e., when a data block In version B is being read. 
The 00 code is used if the next block is a B or a C. The 
55 01 (P) code is used when the next block is an A, and it 
Is jumped over so that the system can next read another 
B or a C. 

[0130] Transitions from a C block are more complicat- 
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ed because there are seven of them, rather than only 
four as for each of the A and B blocks. If the next block 
Is also a C, the code Is a simple 00 - read the next block. 
If the next block is a B and a jump must be made to 
another C, the code 1 0(P) controls the jump over the A. 
Similarly, the code 11 (P) controls a jump over a B to an- 
other C. It will be recalled that these two codes are used 
to control branches from a C block, depending on wheth- 
er the next block Is an A or B. In either case, If the next 
block Is not to be read, ft (and blocks like It) must be 
Jumped over to the next C. 

[01 31 ] However, after reading a C block, it Is also pos- 
sible to read an A or a B. To read an A, one of the codes 
1 1 (P) or 10[P] is used. The 11 code is employed when 
the next block is a B, in which case the pointer is re- 
quired. The 10 code is used when the next block is an 
A, in which case the pointer is not used. Similarly, to read 
a B block next, either the code 10(P) or 11 [P] is used. 
The former is employed when the next block on the disk 
Is an A, and the pointer is required because this block 
must be jumped over. On the other hand, If the next 
block Is a B, the code 1 1 tells the system to go on to this 
next block, and In the process to ignore the pointer be- 
cause it is not needed. 

[01 32] Perhaps the most Important point to recognize 
Is one which is not apparent from the drawings, and that 
is that most blocks will contain 00 pointer flags and no 
pointers. (The 00 code is the only one without a following 
pointer field.) That is because once a frame of either 
version is being played, or once a frame of the common 
material is being played, it Is most likely that the next 
frame will be of the same type. Consequently, a 00 code 
alone does the job. The net result Is that two versions 
of the same motion picture can be stored on the disk, 
with the user having the option of playing either (provid- 
ed that it is allowed by the parental lock), and only a tiny 
fraction of the total disk real estate is "wasted" by house- 
keeping bits that control transitions from one block to 
the next block which is to be read after it. Again, this is 
in line with the underlying design philosophy of providing 
maximum flexibility and as many options as possible, 
without unduly wasting bits In the process. 
[01 33] It should also be noted that the Invention is not 
limited to placing just two versions of a motion picture 
on a disk. It Is possible to use the same technique with 
three or more versions (although the need for so many 
versions is less likely). In such a case, common blocks 
would require two pointers, not just one. If there are 
three versions on the disk, following a C block, the next 
block might be an A, B or D. Two pointers would be re- 
quired to point to the two blocks which are to be found 
further down the line. Obviously, this Is just one of the 
changes which would have to be made. The point is that 
multiple versions can be accommodated, albeit with an 
expenditure of more housekeeping bits. Nevertheless, 
the total number of pointer bits of this type is still Incon- 
sequential compared with the total number of audio/vid- 
eo bits. 



Data Block Fields 

[0134] FIG. 4 depicts the fields of a data block, and 
the format is similar to that shown for the fields of the 
s lead-in track in FIG. 3. Every data block begins with a 
sync word. As discussed above, the sync word pattern 
cannot appear in the data, and thus when it is detected 
the operating system knows that a new data block is 
about to begin. 

10 [0135] The second field is a 20-bit serial block 
number. All of the blocks on the disk are numbered In 
serial order. The block number is the first thing read be- 
cause It is used by block number/pointer analyzer 47 in 
FIG. 2. The block number Is essential, for example, 

15 when jumping from one block to another. The read head 
will usually be positioned at a point near the desired 
block, but it Is highly unlikely that the correct block will 
be selected on the first try. This is especially true since 
the number of bits in the data blocks Is variable, and the 

20 system has no way of knowing how many bits there are 
in the blocks being skipped. By reading the block 
number at the start of the data block, the system can 
quickly determine whether the head must be reposi- 
tioned. 

25 [0136] The third field is a two-bit code which repre- 
sents whether the block is part of the A version, the B 
version, or common to both. (Only three of the four pos- 
sible codes are used.) It might be wondered why the sys- 
tem would ever have to check on the version of a par- 
se ticular block, since once play of version A or version B 
begins, the pointers discussed in connection with FIGS. 
7A and 7B will always identify a block which is either 
common or part of the version being played. The answer 
has to do with fast forward and fast reverse operations. 

35 Although these have not been discussed at length be- 
cause they are entirely conventional techniques, when 
fast forwarding, for example, the read head may be po- 
sitioned more or less arbitrarily. The video should not be 
shown if it Is of the wrong version. It is not possible to 

40 determine the version of a block simply by looking atthe 
block number or the pointer. Neither Identify the version. 
It is for this reason that the system must be able to de- 
termine the version of the block when it is first read. 
[0137] Fields 4 and 5 contain the two-bit pointer flag 

45 and 20-bit pointer which have been explained at length 
In connection with FIGS, 7A and 7B, 
[0138] Field 6 Is a one-bit flag which may or may not 
be present Referring to FIG. 3, the video availability flag 
In field 19 tells the operating system whether there is 

so any video in the data blocks. Even if there is, however, 
It does not mean that every data block contains video. 
For a system in which there Is.a single frame represent- 
ed in every data block, and data blocks are processed 
at a fixed rate, there would be video In every data block, 

55 even if it Is "minimal" video which consists of a code rep- 
resenting a "no change." But there may be systems in 
which a data block may represent more or less than a 
single frame. For example, it may be that the video In- 
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formation in a data block, if present at all, is always of 
the same number of bits. Depending upon the compres- 
sion, it may be that many frames are represented in a 
single data block. In such a case, some of the blocks 
would be devoid of video bits. Depending upon the cod- 
ing scheme employed, the bit in field 6 Informs the op- 
erating system whether there is a field 7 at all. If there 
is video, field 7 contains the video information, terminat- 
ing with a sync word. As mentioned above, the actual 
coding of the video and audio blocks does not comprise 
part of the subject Invention. Although MPEG schemes 
are preferred, others can be used. 
[0139] Field 8 contains anywhere from no bits up to 
1 6. It will be recalled that field 6 of the lead-in track con- 
tains 100 bit positions, but only N of these (where the 
maximum N is 1 6) can represent bits of value 1 because 
there can be at most 1 6 audio tracks on the disk (of 
which M&E Is considered to be one of them). For each 
of these N tracks, field 8 informs the operating system 
whether there is any audio in the present data block. 
There are thus X "1 "s, up to a maximum of N. The first 
bit position of N-bit field 8 corresponds with the first au- 
dio language track Identified in field 6 of the lead-in 
track. The second bit in field 8 of a data block is asso- 
ciated with the second audio language represented in 
field 6 of the lead-in track, etc. The reason that there are 
only N (maximum = 16) bits In field 8 of FIG. 4, rather 
than 1 00, is that It is known from the lead-in track which 
are the languages that may be present In a data block. 
There is no reason to provide 84 or more bit positions 
in each data block to indicate that the corresponding lan- 
guages are not present when it is known from the lead- 
in track that they are nowhere to be found on the disk. 
It must be borne in mind that the value X in FIG. 4 does 
not equal the value N in FIG. 3. The latter represents 
the total number of audio languages any-where on the 
disk, and Its maximum value Is 1 6. The symbol X repre- 
sents how many of those N are actually represented In 
the current data block. 

[01 40] Field 9 contains the X audio language blocks. 
Suppose that there are 1 0 audio languages represented 
on the disk, but only six of them are represented In the 
current data block. In this case, there would be X bit se- 
quences corresponding to the audio languages, each 
ending with an escape character. The escape character 
is used to separate audio blocks from each other. If 
whenever an audio block Is present it has a fixed dura- 
tion, then, since it is known how many audio blocks are 
present in a data block from the information in field 8, it 
is not necessary to provide a sync word at the end of 
the field. Variable length audio blocks would require a 
sync word at the end of the field. 
[0141] Field 9 in the lead-in track contains a value 
from 0 to 63 which represents the number of "other" au- 
dio tracks. While there may be M such "other" audio 
tracks, as shown In FIG. 3, it does not mean that each 
of them is represented In the current data block. Field 
10 in each data block contains M bits, one for each of 



the "other audio tracks on the disk. Whether the current 
data block actually contains bit information for any of 
these M tracks depends on whether the corresponding 
bit position in field 10 contains a 1 . If there are Y "1 B s 

5 and Y is less than M, it means that not all of the "other" 
audio tracks are represented In the current data block. 
Field 11 contains Y "other" audio track blocks, each end- 
ing with an escape character. It will be appreciated that 
the way the audio tracks and the "other" audio tracks 

10 are represented In the -data block are comparable. 
[01 42] Referring back to FIG. 2, It will be recalled that 
data bits in a data block are distributed to audio buffers, 
a video buffer, a pan scan buffer and a subtitle buffer, 
as well as to master controller 41 over the COM-MAND/ 

15 DATA line 65. Thus far. the representation of audio 
blocks, "other" audio blocks and a video block have 
been considered in the analysis of the fields of FIG, 4. 
Before proceeding with the representation of the subtitle 
data, however, it must be understood that there is a dif- 

20 ference in the way that subtitle information is represent- 
ed, as opposed to all audio and video data. The latter is 
represented on a block-by-block basis, and the buffers 
are continuously replenished with new audio and video 
data. Subtitles, on the other hand, need not change from 

25 frame to frame. In fact, a subtitle will not even be per- 
ceived if It does not remain on the screen for more than 
one frame. Consequently, once subtitle data is repre- 
sented In buffer 59 If FIG. 2, it causes a subtitle to be 
formed on the display and to remain there until new sub- 
so title information is loaded into the buffer. To remove a 
subtitle without Introducing a new one, a new subtitle 
consisting of a blank field Is loaded into the buffer. 
[0143] Field 12 in the data block consists of P bits, 
each corresponding with a different one of the P subtitle 
. 35 languages identified in field 15 of the lead-in track. (It 
will be recalled that the first position in every 100-bit fie Id 
corresponding to languages does not really represent a 
language, but rather M&E, so that there are a maximum 
of 99 subtitle languages.) Any subtitle for which there is 

40 an update In the current data block has a 1 In Its corre- 
sponding position In field 12. There can be up to Z n 1"s, 
where the maximum value of Z is P. 
[0144] For each subtitle language for which there is 
an update in the current data block, the update appears 

45 jn field 1 3. There are Z update blocks, each ending with 
an escape character. It Is important to understand that 
an update block can be a blank field. This is the way in 
which a subtitle is removed when a new subtitle Is not 
yet to take its place. 

so [0145] Field 1 4 consists of one bit which may or may 
not be present. The field is present only if field 21 In the 
lead-in track is a 1 . In such a case, pan scan information 
Is available in the data blocks. If pan scan information 
Is available, each data block must tell the operating sys- 

55 tern whether It actually contains a new starting column 
for the pan scan. Field 14 is a single bit, a flag, which 
Indicates whether there is a pan scan update. If the bit 
Is a 1 , field 1 5 is a 9-bit column number, I.e., a pan scan 
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update. 

[01 46] Finally, field 1 6 is a single bit which may or may 
not be present, depending on the value of field 30 in the 
lead-in track. This one-bit flag in the lead-in track tells 
the operating system whether supplemental commands 
and data may be present In field 17 of a data block. If 
the command/data present flag Is a 1 , the command/ 
data block is read from field 17. The field ends with an 
escape character. 

[0147] A data block field thus contains up to six differ- 
ent types of data - audio, "other" audio, video, pan scan 
information, subtitles and a command/data block. These 
are the six types of information which were discussed 
above in connection with FIG. 2, with demultiplexer 63 
distributing the different blocks of information to the au- 
dio buffers, video buffer, pan scan buffer, subtitle buffer 
and master controller. 

Processing Of The Data Block Fields 

[0148] The processing of the data In a data block Is 
relatively straightforward. The processing shown in the 
flowchart of FIG. 6 dovetails with the data block fields 
themselves shown In FIG. 4. 

[0149] It has already been described how block 
number/pointer analyzer 47 on FIG. 2 processes the se- 
rial block number, version, two-bit polnterflag and point- 
er contained in fields 2-5 of a data block. The next field 
is the video present flag. As shown on FIG. 6, If It is de- 
termined that video data is present, video buffer 55 on 
FIG. 2 Is loaded with the video in field 7. If video data is 
not present, the buffer simply has a marker loaded into it. 
[01 50] It is important to understand the need for mark- 
ers. In order for the operating system always to be able 
to synchronize video, audio, subtitle, etc. information, it 
must be able to tell where in the several different buffers 
Is the information from the same data block. In other 
words, the operating system must know which part of 
the audio data in an audio buffer goes with which part 
of video data in the video buffer. Otherwise the various 
Information Items cannot be synchronized with each 
other. By providing markers in the buffers for data which 
Is not present in the data blocks, the operating system 
can keep the various Items of Information synchronized 
with each other. 

[0151] Next, the operating system looks at field 8 to 
. determine how many of the N audio tracks on the disk 
(see FIG. 3) actually are represented In the current data 
block. The same Is true of the M "other" audio tracks 
represented In field 1 0. All of the audio and "other" audio 
track data are loaded into their respective buffers. The 
flowchart shows the sequencing only for the first and last 
of the audio tracks. In each case, a test is performed to 
see whether the audio track or "other" audio track has 
data present In the current data block. Each of the tracks 
results in something being loaded In Its respective buffer 
- either actual data followed by a marker, or a marker 
alone. 



[0152] After the video and audio information, a data 
block contains subtitle updates. If there Is update infor- 
mation for the subtitles in the selected language, it is 
loaded in the subtitle buffer otherwise a marker alone 
5 is stored. The three blocks pertaining to subtitles pertain 
only to a single track, that corresponding to the selected 
subtitle language. 

[0153] Next, the pan scan update flag In field 14 Is 
read. If pan scan update Information Is present, It also 

10 gets loaded, this time In a pan scan buffer. If no new 
information is available, a marker Is simply placed in the 
pan scan buffer to indicate that another data block has 
gone by with no new pan scan update information. 
[0154] Finally, the system determines whether there 

1 5 are commands or data available (if the lead-in track field 
30 says that commands or data are to be found at all in 
the data blocks). If command/data Is present, i.e., field 
1 6 in the data block is a 1 , It is loaded from field 17 into 
memory in the master controller 41 of FIG. 2. If there 

20 are no commands or data available only a marker is 
loaded in the microprocessor memory. 
[0155] It should be noted that none of the processing 
sequences of FIG. 6 shows a check being made wheth- 
er the respective type of Information Is available on the 

25 disk In the first place. But it is to be understood that a 
test such as "Is command/data present?" really consists 
of two parts. First, is the data block command/data flag 
In field 30 of the lead-in track a 0 or 1 ? If it is a 0, com- 
mands and data are not even looked for during the 

so processing of a data block. On the other hand, if com- 
mand or data may be present in a data block as a result 
of the data flag in field 30 of the lead-in track being a 1 , 
then each data block has its field 1 6 checked to see 
whether the command/data present flag is a 1 . It is the 

35 value of the flag in the data block field which determines 
whether only a marker gets loaded, or a marker follow- 
ing data bits. Similar remarks apply to the other se- 
quences. For example, there Is no reason to check 
whether a pan scan update is present If from the lead- 

40 in track It Is determined that pan scan information Is no- 
where present on the disk. 

Claims 

45 

1 . A digital software carrier and a compatible player 
that controls display of subtitles during play of the 
software carrier, said software carrier having re- 
corded thereon 

so 

i) data representing a video program, and 

ii) data representing a plurality of subtitle 
tracks, each track containing subtitle data rep- 
resentative of subtitles in a respective lan- 

55 guage, said player operating to 

(a) play said software carrier and derive 
therefrom said subtitle data and a video 
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program, 

(b) select for display a subtitle language 
from those represented on said software 
carrier, and 

(c) process the subtitle data representative s 
of subtitles in the selected language and 
control display of such subtitles synchro- 
nized with said video program, 

and wherein said video program data and said data 10 
in said plurality of subtitle tracks are recorded se- 
quentially In separately identifiable blocks that can 
vary in size on said software carrier, with multiple 
different types of <Jata representing a video program 
and a plurality of subtitle tracks that may be record- is 
ed In any individual carrier block, and with any indi- 
vidual carrier block having variable-length sections 
for the different types of data representing a video 
program and said plurality of subtitle tracks, and 
containing indicia of which subtitle tracks in the car- 20 
rler block contain subtitle data, said carrier blocks 
not requiring any data beyond that required for con- 
tra I and program Information. 

2. A digital software carrier and compatible player In 25 
accordance with claim 1 wherein said carrier further 
has recorded thereon 

ill) data representing at least one audio track 
synchronized with said video program, and 30 
iv) a set of subtitle codes for indicating the avail- 
able subtitle languages, wherein the data rep- 
resenting said at least one audio track is re- 
corded with said video program data and said 
data in said plurality of subtitle tracks sequen- 35 
tiaily in separately identifiable blocks on said 
software carrier, with said multiple different 
types of data In any Individual carrier block also 
representing said at least one audio track, and 
with said carrier blocks having variable-length 40 
sections for the data representing said at least 
one audio track as well as the data representing 
said video program and the data in said plurality 
of subtitle tracks. 

45 

3. A digital software carrier for play in a compatible 
player that controls display of subtitles during play 
of the software carrier, said software carrier having 
recorded thereon 

so 

i) data representing a video program, and 
H) data representing a plurality of subtitle 
tracks, each track containing subtitle data rep- 
resentative of subtitles in a respective lan- 
guage, 55 

and wherein said video program data and said data 
In said plurality of subtitle tracks are recorded se- 



quentially In separately identifiable blocks that can 
vary in size on said software carrier, with multiple 
different types of data representing a video program 
and a plurality of subtitle tracks that may be record- 
ed in any individual carrier block, and with any indi- 
vidual carrier block having variable-length sections 
for the different types of data representing a video 
program and said plurality of subtitle tracks, and 
containing indicia of which subtitle tracks in the car- 
rier block contain subtitle data, said carrier blocks 
not requiring any data beyond that required for con- 
trol and program Information. 

4. A digital software carrier in accordance with claim 
3 wherein said carrier further has recorded thereon 

ili) data representing at least one audio track 
synchronized with said video program, and 
iv) a set of subtitle codes for indicating the avail- 
able subtitle languages, 

wherein the data representing said at least one au- 
dio track is recorded with said video program data 
and said data In said plurality of subtitle tracks se- 
quentially in separately Identifiable blocks on said 
software carrier, with said multiple different types of 
data in any individual carrier block also representing 
said at least one audio track, and with said carrier 
blocks having variable-length sections for the data 
representing said at least one audio track as well 
as the data representing said video program and 
the data In said plurality of subtitle tracks. 

5. A data stream containable in or derivable from a dig- 
ital software carrier, and a system for processing the 
data stream, wherein the system controls display of 
subtitles during processing of the data stream, said 
data stream having 

I) data representing a video program, and 
li) data representing a plurality of subtitle 
tracks, each track containing subtitle data rep- 
resentative of subtitles In a respective lan- 
guage, said system operating to 

(a) process said data stream and derive 
therefrom said subtitle data and a video 
program, 

(b) select for display a subtitle -language 
from those represented in said data 
stream, and 

(c) process the subtitle data representative 
of subtitles in the selected language and 
control display of such subtitles synchro- 
nized with said video program, 

and wherein said video program data and said data 
in said plurality of subtitle tracks are contained se- 
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quentially in separately identifiable blocks that can 
vary in size in said data stream, with multiple differ- 
ent types of data representing a video program and 
a plurality of subtitle tracks that may be contained 
in any individual block, and with any individual block 5 
having variable-length sections for the different 
types of data representing a video program and said 
plurality of subtitle tracks, and containing indicia of 
which subtitle tracks In the block contain subtitle da- 
ta, said blocks not requiring any data beyond that 10 
required for control and program information. 

6. A data stream In accordance with claim 5 wherein 
said data stream further contains 

15 

iii) data representing at least one audio track 
synchronized with said video program, and 

iv) a set of subtitle codes for indicating the avail- 
able subtitle languages, wherein the data rep- 
resenting said at least one audio track con- 20 
tained with said video program data and said 
data in said plurality of subtitle tracks sequen- 
tially In separately identifiable blocks In said da- 
ta stream, with said multiple different types of 
data In any individual block also representing 25 
said at least one audio track, and with said 
blocks having variable-length sections for the 
data representing said at least one audio track 

as well as the data representing said video pro- 
gram and the data in said plurality of subtitle 30 
tracks. 

7. A data stream containable in or derivable from a dig- 
ital software carrier for processing by a system that 
controls display of subtitles during processing of the 35 
data stream, said data stream having 

I) data representing a video program, and 
ii) data representing a plurality of subtitle 
tracks, each track containing subtitle data rep- *o 
resentatlve of subtitles In a respective lan- 
guage, 

and wherein said video program data and said data 
in said plurality of subtitle tracks are contained se- 4s 
quentially in separately identifiable blocks that can 
vary in size in said data stream, with multiple differ- 
ent types of data representing a video program and 
a plurality of subtitle tracks that may- be contained 
in any Individual block, and with any individual block 50 
having variable-length sections for the different 
types of data representing a video program and said 
plurality of subtitle tracks, and containing indicia of 
which subtitle tracks in the block contain subtitle da- 
ta, said blocks not requiring any data beyond that ss 
required for control and program Information. 

8. A data stream In accordance with claim 7 wherein 



said data stream further contains 

iii) data representing at least one audio track 
synchronized with said video program, and 
Iv) a set of subtitle codes for indicating the avail- 
able subtitle languages, and 

wherein the data representing said at least one au- 
dio track Is contained with said video program data 
and said data in said plurality of subtitle tracks se- 
quentially In separately Identifiable blocks in said 
data stream, with said multiple different types of da- 
ta in any individual block also representing said at 
least one audio track, and with said blocks having 
variable-length sections for the data representing 
said at least one audio track as well as the data rep- 
resenting said video program and the data in said 
plurality of subtitle tracks. 



Patents nsprUche 

1. Digltaler Softwaretrager und kompatibies Wleder- 
gabegerat, das elne Anzeige von Untertiteln wah- 
rend einer Wiedergabe des Softwaretragers steu- 
ert, wobel der Softwaretrager darauf aufgezeichnet 
aufwejst: 

i) Daten, die ein Videoprogramm darstellen, 
und 

ii) Daten, die eine Vielzahl von Untertitelspuren 
darstellen, wobel jede Spur Untertlteldaten ent- 
halt, die darsteilend fur Untertitel in elner jewei- 
iigen Sprache sind, wobel das Wiedergabege- 
rat arbeitet, urn 

(a) den Softwaretrager wiederzugeben 
und davon die Untertiteldaten und ein Vi- 
deoprogramm abzulelten, 

(b) fur eine Anzeige eine Untertitelsprache 
von jenen zu wahlen, die auf dem Soft- 
waretrager dargestellt sind, und 

(c) die Untertiteldaten zu verarbeiten, die 
darsteilend ftir Untertitel in der gewahlten 
Sprache sind, und elne Anzeige derartiger 
Untertitel zu steuern, die mlt dem Video- 
programm synchronisiert sind, 

und wobel Vldeoprogrammdaten und die Da- 
ten in der Vielzahl von Untertitelspuren sequentiell 
In getrennt identlfizlerbaren Blocken aufgezeichnet 
sind, die in elner GroBe auf dem Softwaretrager va- 
rileren konnen, wobel mehrfache unterschledllche 
Typen von Daten ein Videoprogramm und elne Viel- 
zahl von Untertiteldaten darstellen, die in Jedwedem 
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individuellen Tragerbiock aufgezeichnet sein kon- 
nen, und wobei jedweder individuelle Tragerbiock 
Abschnitte variabler Lange fur die unterschiedll- 
chen Typen von Daten aufweist, die ein Videopro- 
gramm und die Vielzahl von Untertiteldaten darstel- 5 
len t und die Anzelgen enthalten, welche Untertitel- 
spuren In dem Tragerbiock Untertiteldaten enthal- 
ten, wobei die Tragerblocke jedwede Daten auBer 
Jenen, die fur eine Steuerung und elne Programm- 
information erforderiich sind, nlcht benotlgen. 10 

2. Dlgltaler Softwaretrager und kompatlbles Wieder- 
gabegerat in Oberelnstlmmung mit Anspruch 1 , wo- 
bei der Trager welter darauf aufgezeichnet aufweist 

15 

Hi) Daten, die zumindest eine Audiospur dar- 
stellen, die mit dem Videoprogramm synchro- 
nisiert ist, und 

iv) einen Satz von Untertitelcodes zum Anzei- so 
gen der verfugbaren Untertitelsprachen, wobei 
die Daten, die die zumindest eine Audiospur 
darsteilen, mit den Vldeoprogrammdaten und 
den Daten in der Vielzahl von Untertitelspuren 
sequentiell in getrennt Identifizierbaren Blok- ss 
ken auf dem Softwaretrager aufgezeichnet 
sind, wobei die mehrfachen unterschiedlichen 
Typen von Daten In Jedwedem individuellen 
Tragerbiock auch die zumindest eine Audio- 
spur darstelien, und wobei die Tragerblocke 30 
Abschnitte variabler Lange fur die Daten auf- 
welsen, die die zumindest eine Audiospur dar- 
stelien, wie auch die Daten, die das Videopro- 
gramm und die Daten in der Vielzahl von Un- 
tertitelspuren darsteilen. 35 

3. Dlgltaler Softwaretrager zur Wiedergabe in einem 
kompatlblen Wiedergabegerat, das eine Anzeige 
von Untertlteln wahrend einer Wiedergabe des 
Softwaretragers steuert, wobei der Softwaretrager 40 
darauf aufgezeichnet aufweist 

i) Daten, die eln Videoprogramm darsteilen, 
und 

45 

ii) Daten, die eine Vielzahl von Untertitelspuren 
darsteilen, wobei jede Spur Untertiteldaten ent- 
halt, die darsteilend fur Untertitel in einer jewei- 
ligen Sprache sind, 

50 

und wobei die Vldeoprogrammdaten und die 
Daten in der Vielzahl von Untertitelspuren sequen- 
tiell In getrennt identifizierbaren Blocken aufge- 
zeichnet sind, die in einer GroBe auf dem Software- 
trager variieren konnen, wobei mehrfache unter- 55 
schiedliche Typen von Daten ein Videoprogramm 
und elne Vielzahl von Untertitelspuren darsteilen, 
die In jedwedem Individuellen Tragerbiock aufge- 



zeichnet sein konnen, und wobei jedweder indivi- 
dueller Tragerbiock Abschnitte variabler Lange fur 
die unterschiedlichen Typen von Daten, die ein Vi- 
deoprogramm darsteilen, und die Vielzahl von Un- 
tertitelspuren aufweist und Anzeigen daruber ent- 
halt, welche Untertitelspuren in dem Tragerbiock 
Untertiteldaten enthalten, wobei die Tragerblocke 
nlcht irgendwelche Daten auBer jenen fur eine 
Steuerung und eine Programmlnformation erforder- 
llchen benotlgen. 

4. Dlgltaler Softwaretrager in Obereinstirhmung mit 
Anspruch 3, wobei der Trager weiter darauf aufge-. 
zeichnet aufweist 

Hi) Daten, die zumindest eine Audiospur dar- 
steilen, die mit dem Videoprogramm synchro- 
nisiert ist, und 

iv) einen Satz von Untertitelcodes zum Anzei- 
gen der verfugbaren Untertitelsprachen, wobei 
die Daten, die zumindest eine Audiospur dar- 
steilen, mit den Vldeoprogrammdaten und den 
Daten in der Vielzahl von Untertitelspuren se- 
quentiell In getrennt Identifizierbaren Blocken 
auf dem Softwaretrager aufgezeichnet sind, 
wobei die mehrfachen unterschiedlichen Typen 
von Daten in Jedwedem individuellen Trager- 
biock auch die zumindest eine Audiospur dar- 
steilen, und wobei die Tragerblocke Abschnitte 
variabler Lange fur die Daten, die die zumin- 
dest eine Audiospur darsteilen, wle auch die 
Daten, die das Videoprogramm und die Daten 
in der Vielzahl von Untertitelspuren darsteilen, 
aufweisen. 

5. Datenstrom, der enthaltbar In Oder ableltbar von ei- 
nem digitalen Softwaretrager 1st, und ein System 
zur Verarbeitung des Datenstroms, wobei das Sy- 
stem eine Anzeige von Untertiteln wahrend einer 
Verarbeitung des Datenstroms steuert, wobei der 
Datenstrom aufweist 

i) Daten, die ein Videoprogramm darstelien, 
und 

ii) Daten, die eine vielzahl von Untertitelspuren 
darstelien, wobei jede Spur Untertiteldaten ent- 
halt, die darsteilend fur Untertitel in einer jewei- 
ligen Sprache sind, wobei das System arbeitet, 
urn 

(a) den Datenstrom zu verarbeiten und da- 
von die Untertiteldaten und ein Videopro- 
gramm abzuleiten, 

(b) fur elne Anzeige eine Untertitelsprache 
von Jenen in dem Datenstrom dargestellten 
zu wahlen, und 
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(c) die Untertiteldaten, die darstellend fur 
Untertitel in der gewahlten Sprache sind, 
zu verarbeiten und eine Anzeige von der- 
artigen Untertiteln, die mit dem Videopro- 
gramm synchronlsiert sind, zu steuem, s 

und wobel die Videoprogrammdaten und die 
Daten in der Vielzahl von Untertitelspuren sequen- 
tial in getrennt identiflzierbaren Blacken enthalten 
sind, die in einer GroBe in dem Datenstrom varile- 10 
ren konnen, wobei mehrfache unterschiedliche Ty- 
pen von Daten ein Videoprogramm und eine Viel- 
zahl von Untertitelspuren darstellen, die in jedwe- 
dem individueiien Block enthalten sein konnen, und 
wobel jedweder individuelle Block Abschnitte varia- is 
bier Lange fur die unterschiedlichen Typen von Da- 
ten, die ein Videoprogramm und die Vielzahl von 
Untertitelspuren darstellen, aufweist und Anzeigen 
daruber enthalt, welche Untertitelspuren in dem 
Block Untertiteldaten enthalten, wobei die Biocke 20 
nicht Irgendwelche Daten auSer Jenen fur eine 
Steuerung und eine Programmlnf ormatlon erforder- 
llchen benotigen. 

6. Datenstrom nach Anspruch 5, wobel der Daten- 25 
strom welter enthalt 

Hi) Daten, die zumlndest eine Audiospur dar- 
stellen, die mlt dem Videoprogramm synchro- 
nisiert 1st, und 30 
(Iv) einen Satz von Untertitelcodes zum Anzei- 
gen derverfugbaren Untertitelsprachen, 

wobei die Daten, die die zumindest eine Au- 
diospur darstellen, mit den Videoprogrammdaten 3S 
und den Daten in der Vielzahl von Untertitelspuren 
sequentlell in getrennt Identifizierbaren Blocken In 
dem Datenstrom enthalten sind, wobel die mehrfa- 
chen unterschiedlichen Typen von Daten in jedwe- 
dem individueiien Block auch die zumindest eine 40 
Audiospur darstellen, und wobel die Biocke Ab- 
schnitte variabier Lange fQr die Daten aufweisen, 
die die zumindest eine Audiospur darstellen, wle 
auch die Daten, die das Videoprogramm und die 
Daten In der Vielzahl von Untertitelspuren darstel- 45 
len. 

7. Datenstrom, der enthaltbar in oder ableitbar von ei- 
nem digitalen Softwaretrager zur Verarbertung 
durch ein System ist, das eine Anzeige von Unter- so 
titeln wahrend elner Verarbeitung des Datenstroms 
steuert, wobei der Datenstrom aufweist 

i) Daten, die ein Videoprogramm darstellen, 
und 55 
il) Daten, die eine Vielzahl von Untertitelspuren 
darstellen , wobel Jede Spur U ntertiteldaten ent- 
halt, die darstellend fur Untertitel In einer jewei : 



Ngen Sprache sind, 

und wobei die Videoprogrammdaten und die 
Daten in der Vielzahl von Untertitelspuren sequen- 
tiell in getrennt identifizierbaren Blocken enthalten 
sind, die in elner GroBe In dem Datenstrom variie- 
ren konnen, wobel mehrfache unterschledliche Ty- 
pen von Daten ein Videoprogramm und eine Viel- 
zahl von Untertitelspuren darstellen, die in Jedwe- 
dem IndlvidUellen Block enthalten sein konnen, und 
wobei jedweder individuelle Block Abschnitte varia- 
bier Lange fur die unterschiedlichen Typen von Da- 
ten, die ein Videoprogramm und die Vielzahl von 
Untertitelspuren darstellen, aufweist und Anzeigen 
enthalt, welche Untertitelspuren In dem Block Un- 
tertiteldaten enthalten, wobei die Biocke nicht ir- 
gendwelche Daten auBer jenen fur eine Steuerung 
und eine Programminformation erforderlichen be- 
notigen. 

8. Datenstrom nach Anspruch 7, wobei der Daten- 
strom welter enthalt 

HI) Daten, die zumindest eine Audiospur dar- 
stellen, die mit dem Videoprogramm synchro- 
nlsiert 1st, und 

iv) einen Satz von Untertitelcodes zum Anzei- 
gen der verfugbaren Untertitelsprachen, und 

wobel die Daten, die die zumindest eine Au- 
diospur darstellen, mit den Videoprogrammdaten 
und den Daten in der Vielzahl von Untertitelspuren 
sequentlell in getrennt identifizierbaren Blocken in 
dem Datenstrom enthalten sind, wobei die mehrfa- 
chen unterschiedlichen Typen von Daten In jedwe- 
dem Individueiien Block auch die zumindest eine 
Audiospur darstellen, und wobel die Biocke Ab- 
schnitte varlabler Lange fur die Daten, die die zu- 
mindest eine Audiospur darstellen, wie auch die 
Daten, die das Videoprogramm und die Daten In der 
Vielzahl von Untertitelspuren darstellen, aufweisen. 



Revendications 

1 . Support d'informatlon logique numerique et lecteur 
compatible qui commande I'afflchage de sous-titres 
pendant une lecture_du support d'information logi- 
que, ledit support d'informatlon logique comportant 
enregistrees sur iui: 

i) des donnees qui represented un programme 
video; et 

II) des donnees qui represented une pluralite 
de pistes de sous-titres, chaque piste cove- 
nant des donnees de sous-titre qui sont repre- 
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sedatives de sous-titres dans une langue res- 
pective, ledit lecteur fonctionnant pour 

(a) lire ledit support d'information logique 
et en deriver lesdites donnees de sous-titre 
et un programme video, 

(b) selectionner en vue d'un affichage une 
langue de sous-titres parmi celles qui sont 
representees sur ledit support d'informa- 
tion logique, et 

(c) tralter les donnees de sous-tltre qui sont 
representatives de sous-titres dans la lan- 
gue sdlectionnee et commander un affi- 
chage de ces sous-titres en synchronisa- 
tion avec ledit programme video, 

et dans lequel lesdites donnees de program- 
me video et lesdites donnees dans ladite pluralite 
de pistes de sous-titres sont enregistrees de facon 
sequentielle dans des blocs identifiables separe- 
ment dont la dimension peut varier sur ledit support 
d'informatlon logique, de multiples types differents 
de donnees representant un programme video et 
une pluralite de pistes de sous-titres qui peuvent 
etre enregistres dans n'lmporte quel bloc de support 
individuei, et n'lmporte quel bloc de support Indivi- 
duel comportant des sections de longueur variable 
pour les differents types de donnees qui represen- 
ted un programme video et ladite pluralite de pistes 
de sous-titres, et contenant des indices des pistes 
de sous-titres dans ie bloc de support qui contien- 
nent des donnees de sous-titre, lesdits blocs de 
support ne necessitant pas de quelconques don- 
nees au-dela de celles requises pour Nnformatlon 
de commande et de programme. 

Support d'informatlon logique numerique et lecteur 
compatible selon la revendication 1 , dans lesquels 
ledit support comporte en outre enregistres sur lui: 

iii) des donnees qui represented au moins une 
piste audio qui est synchronisee avec ledit pro- 
gramme video; et 

iv) un jeu de codes de sous-titre pour indiquer 
les langues de sous-titre disponibles, 



tent ladite au moins une piste audio et les donnees 
qui represented ledit programme video et les don- 
nees dans ladite pluralite de pistes de sous-titres. 

5 3. Support d'informatlon logique numerique pour une 
lecture dans un lecteur compatible qui commande 
un affichage de sous-titres pendant une lecture du 
support d'informatlon logique, ledit support d'infor- 
matlon logique comportant enregistrees sur lui: 

10 

I) des donnees qui represented un programme 
video; et 

II) des donnees qui represented une pluralite 
* 5 de pistes de sous-titres, cheque piste conte- 
nant des donnees de sous-titre qui sont repre- 
sentatives de sous-titres dans une langue res- 
pective, 

20 et dans lequei iesdites donnees de program- 

me video et lesdites donnees dans ladite pluralite 
de pistes de sous-titres sont enregistrees de facon 
sequentielle dans des blocs identifiables separe- 
ment dont la dimension peut varier sur ledit support 

25 d'informatlon logique, de multiples types differents 
de donnees representant un programme video et 
une pluralite de pistes de sous-titres qui peuvent 
etre enregistres dans n'importe quel bloc de support 
individuei, et n'importe quel bloc de support indivi- 

30 duel comportant des sections de longueur variable 
pour les differents types de donnees qui represen- 
ted un programme video et ladite pluralite de pistes 
de sous-titres, et contenant des indices des pistes 
de sous-titres dans le bloc de support qui contien- 

35 nent des donnees de sous-titre, lesdits blocs de 
support ne necessitant pas de quelconques don- 
nees au-dela de celles requises pour I'lnformation 
de commande et de programme. 

40 4. Support d'informatlon logique numerique selon la 
revendication 3, dans lequel ledit support comporte 
en outre enregistres sur lui: 

ill) des donnees qui represented au moins une 
45 pjste audio qui est synchronisee avec ledit pro- 

gramme video; et 



ou les donnees qui represented ladite au 
moins une piste audio sont enregistrees avec les- 
dites donnees de programme video et lesdites don- so 
nees dans ladite pluralite de pistes de sous-titres 
de facon sequentielle dans des blocs identifiables 
separement sur ledit support d'information logique, 
lesdits multiples types differents de donnees dans 
un quelconque bloc de support Individuei represen- ss 
tant egalement ladite au moins une piste audio et 
lesdits blocs de support comportant des sections de 
longueur variable pour les donnees qui represen- 



iv) un Jeu de codes de sous-titre pour indiquer 
les langues de sous-titre disponibles, dans le- 
quel les donnees qui represented ladite au 
moins une piste audio sont enregistrees avec 
lesdites donnees de programme video et lesdi- 
tes donnees dans ladite pluralite de pistes de 
sous-titres de facon sequentielle dans des 
blocs Identifiables separement sur ledit support 
d'information logique, lesdits multiples types 
differents de donnees dans un quelconque bloc 
de support individuei representant egalement 
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ladite au moins une piste audio et lesdits blocs 6. 
de support comportant des sections de lon- 
gueur variable pour les donnees qui represen- 
ted iadite au molns une piste audio et les don- 
nees qui represented ledit programme video et s 
les donnees dans ladite pluralite de pistes de 
sous-titres. 

Train de donnees qui peut etre contenu dans ou de- 
rive a partir d'un support d'Information loglque nu- to 
merique, et systeme pour traiter le train de don- 
nees, dans lesquels le systeme commande un affi- 
chage de sous-titres pendant un traitement du train 
de donnees, ledit train de donnees comportant; 

15 

i) des donnees qui represented un programme 
video; et 

ii) des donnees qui represented une pluralite 

de pistes de sous-titres, chaque piste code- 20 
nant des donnees de sous-titre qui sod repre- 
sentatives de sous-titres dans une langue res- 
pective, ledit systeme fonctionnant pour 

(a) traiter ledit train de donnees et en deri- 25 7. 
ver iesdites donnees de sous-titre et un 
programme video, 

(b) selection ner en vue d'un affichage une 
langue de sous-titre parmi celles qui sont 30 
representees dans ledit train de donnees, 

et 

(c) traiter les donnees de sous-titre qui sont 
representatives de sous-titres dans la Ian- 35 
gue selectionnee et commander un affi- 
chage de ces sous-titres en synchronisa- 
tion avec ledit programme video, 

et dans lequel Iesdites donnees de program- *o 
me video et Iesdites donnees dans ladite pluralite 
de pistes de sous-titres sont contenues de fagon se- 
quentielle dans des blocs identiflables separement 
dont la dimension peut varier dans ledit train de 
donnees, de multiples types differents de donnees 45 
represented un programme video et une pluralite 
de pistes de sous-titre qui peuvent etre contenus 
dans n'importe quel bloc individuel, et n'importe 
quel bloc individuel comportant des sections de lon- 
gueur variable pour les differents types de donnees so 
qui represented un programme video et ladite plu- 
ralite de pistes de sous-titres, et contenant des in- 
dices des pistes de sous-titres dans le bloc qui con- 
tiennent des donnees de sous-titre, lesdits blocs ne 
necessitant pas de quelconques donnees au-dela 55 
de celles requises pour Pinformation de commande 
et de programme. 



Train de donnees selon la revendication 5, dans le- 
quel ledit train de donnees contient en outre: 

Hi) des donnees qui represented au moins une 
piste audio qui est synchronised avec ledit pro- 
gramme video; et 

Iv) un jeu de codes de sous-titre pour indlquer 
les langues de sous-titre disponibles, dans le- 
quel les donnees qui represented ladite au 
moins une piste audio sont enreglstrees avec 
Iesdites donnees de programme video et Iesdi- 
tes donnees dans ladite pluralite de pistes de 
sous-titres de fagon sequent) ell e dans des 
blocs identiflables separement dans ledit train 
de donnees, lesdits multiples types differents 
de donnees dans un quelconque bloc Individuel 
represented egalement ladite au moins une 
piste audio et lesdits blocs comportant des sec- 
tions de longueur variable pour les donnees qui 
represented ladite au molns une piste audio et 
les donnees qui represented ledit programme 
video et les donnees dans ladite pluralite de 
pistes de sous-titres. 

Train de donnees qui peut etre contenu dans ou de- 
rive a partir d'un support d'information loglque nu- 
merlque pour un traitement a I'alde d'un systeme 
qui commande un affichage de sous-titres pendant 
un traitement du train de donnees, ledit train de don- 
nees comportant: 

i) des donnees qui represented un programme 
video; et 

li) des donnees qui represented une pluralite 
de pistes de sous-titres, chaque piste conte- 
nant des donnees de sous-titre qui sont repre- 
sentatives de sous-titres dans une langue res- 
pective, 

et dans lequel Iesdites donnees de program- 
me video et Iesdites donnees dans ladite pluralite 
de pistes de sous-titres sont enreglstrees de fagon 
sequentielle dans des blocs identiflables separe- 
ment dont la dimension peut varier dans ledit train 
de donnees, de multiples types differents de don- 
nees representant un programme video et une plu- 
ralite de pistes de sous-titres qui peuvent etre con- 
tenus dans n'importe quel bloc indivlduei, et n'im- 
porte quel bloc individuel comportant des sections 
de longueur variable pour les differents types de 
donnees qui represented un programme video et 
ladite pluralite de pistes de sous-titres, et contenant 
des indices des pistes de sous-titres dans le bloc 
qui contlennent des donnees de sous-titre, lesdits 
blocs ne necessitant pas de quelconques donnees 
au-dela de celles requises pour Pinformation de 
commande et de programme. 
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Train de donnees selon la revendication 7, dans le- 
quel iedit train de donnees contient en outre: 

iii) des donnees qui represented au moins une 
piste audio qui est synchronisee avec Iedit pro- 5 
gramme video; et 

iv) un Jeu de codes de sous-titre pour indiquer 
les langues de sous-titre disponibles, 

10 

dans iequel les donnees qui represented la- 
dite au moins une piste audio sont contenues avec 
lesdites donnees de programme video et lesdites 
donnees dans ladite piuralite de pistes de sous-ti- 
tres de facon sequentielle dans des blocs identifia- 15 
bles separement dans Iedit train de donnees, les- 
dits multiples types differents de donnees dans un 
quelconque bloc indivldue! representant egalement 
ladite au moins une piste audio et lesdits blocs com- 
portant des sections de longueur variable pour les 20 
donnees qui represented ladite au moins une piste 
audio et les donnees qui represented Iedit pro- 
gramme video et les donnees dans ladite piuralite 
de pistes de sous-titres. 
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FIG. 4 
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FIG.5A 
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